[issue14035] behavior of test.support.import_fresh_module

2012-06-15 Thread Nick Coghlan
Changes by Nick Coghlan : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue14035] behavior of test.support.import_fresh_module

2012-06-14 Thread Eli Bendersky
Eli Bendersky added the comment: This looks rejected to me. Any opposition to closing the issue? -- ___ Python tracker ___ ___ Python

[issue14035] behavior of test.support.import_fresh_module

2012-02-17 Thread Nick Coghlan
Nick Coghlan added the comment: In the case of *dependencies* that get refreshed, no they're *not* kept in sys.modules - they get overwritten by the originals when the sys.modules state gets restored. The problem almost certainly arises because something, somewhere is doing "from x import y"

[issue14035] behavior of test.support.import_fresh_module

2012-02-17 Thread Florent Xicluna
Florent Xicluna added the comment: I have updated the patch to a simpler form where I copy() sys.modules. Strangely, I do not detect any refleak running the tests. I plan to commit this fix, if we don't have leaks in the test suite. -- resolution: -> duplicate Added file: http://bugs.

[issue14035] behavior of test.support.import_fresh_module

2012-02-17 Thread Florent Xicluna
Changes by Florent Xicluna : Removed file: http://bugs.python.org/file24537/issue14035_fresh_modules.diff ___ Python tracker ___ ___ Python-bu

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Eli Bendersky
Eli Bendersky added the comment: Florent, I can reproduce the problem by leaving just the last import_fresh_module in test_fresh_import.py And your patch fixes it, although as Nick says it's problematic in terms of ref leaks. What I'm not sure about is why the extra reference is needed. The

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Nick Coghlan
Nick Coghlan added the comment: Keeping module references implicitly in import_fresh_module will leak references like crazy in the test suite. The onus is on the code referencing module contents to ensure that the module globals remain valid. If we get rid of the explicit clearing of module g

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Florent Xicluna
Florent Xicluna added the comment: Keeping reference of fresh modules solves the issue. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file24537/issue14035_fresh_modules.diff ___ Python tracker

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Florent Xicluna
Florent Xicluna added the comment: Trigger the same behavior without import_fresh_module. (test_fresh_import2.py) If you uncomment line #A or #B, it succeed. On the other side, if you comment line #C or #D, it succeed too. The import machinery is a bit complex, indeed ... -- nosy: +br

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Florent Xicluna
Changes by Florent Xicluna : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue14035] behavior of test.support.import_fresh_module

2012-02-16 Thread Florent Xicluna
New submission from Florent Xicluna : While writing tests xml.etree, I hit a strange behaviour of import_fresh_module. How to reproduce: - dummy/__init__.py - dummy/foo.py - dummy/bar.py - test_fresh_import.py # 'dummy/foo.py' from dummy.bar import func # 'dummy/bar.py' fortytwo = 42 def fun