[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-17 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: *grumble*grumble*os-x-and-its-crazy-symlink-as-tmp-dir*grumble*grumble* I'm fairly sure I've tripped over this kind of thing before, so I believe I know how to fix it (add a realpath() call when figuring out the expected path value). The

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-17 Thread Roundup Robot
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 07ed744a47f6 by Nick Coghlan in branch '3.2': Issue #15230: Attempt to make the OS X buildbots happy by resolving the tmp dir symlink in the test suite http://hg.python.org/cpython/rev/07ed744a47f6 New changeset

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-17 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: Closing again, since the OS X buildbot was happy with the change on 3.2. If trunk fails (which it shouldn't), that should be filed as a new issue (as it would almost certainly relate to the move from the pkgutil emulation to importlib).

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-16 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr added the comment: This broke some 3.2 buildbots, e.g.: http://buildbot.python.org/all/builders/AMD64%20Lion%203.2/builds/25 -- nosy: +pitrou status: closed - open ___ Python tracker rep...@bugs.python.org

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-14 Thread Roundup Robot
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3b05cf877124 by Nick Coghlan in branch '3.2': Close #15230: runpy.run_path now sets __package__ correctly. Also refactored the runpy tests to use a more systematic approach

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-14 Thread Roundup Robot
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 4880aac5c665 by Nick Coghlan in branch '3.2': Issue #15230: Update runpy docs to clarify a couple of points that came up in this issue http://hg.python.org/cpython/rev/4880aac5c665 New changeset 416cd57d38cf by

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-10 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15230 ___

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-07 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: Firstly, I think you've identified a real bug with __package__ not being set correctly when using runpy.run_path (and I have updated this issue title accordingly). I have also created a separate bug report (#15272) for the bizarre behaviour

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-07 Thread Nick Coghlan
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15230 ___ ___ Python-bugs-list

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-07 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: You may also have identified a bug with pkgutil's import emulation failing to clean up sys.modules correctly when an import fails. -- ___ Python tracker rep...@bugs.python.org

[issue15230] runpy.run_path doesn't set __package__ correctly

2012-07-07 Thread Nick Coghlan
Nick Coghlan ncogh...@gmail.com added the comment: Sorry, that's not accurate - you have enough code in b.py to make the relative import work by convincing the interpreter it's actually being done in a package. So what you're seeing in that regard is the fact that runpy is not any kind of