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

[Nick Coghlan]

Nick Coghlan  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).

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

Roundup Robot  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 cb7e8ee489a1 by Nick Coghlan in branch 'default':
Merge Issue #15230 OS X buildbot fix from 3.2
http://hg.python.org/cpython/rev/cb7e8ee489a1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan  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 buildbots will let me know if I'm right, of course :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

Roundup Robot  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 Nick Coghlan in branch 'default':
Merge #15230 doc updates from 3.2
http://hg.python.org/cpython/rev/416cd57d38cf

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

Roundup Robot  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
http://hg.python.org/cpython/rev/3b05cf877124

New changeset 8a44e7c0fa30 by Nick Coghlan in branch 'default':
Merge fix for #15230 from 3.2
http://hg.python.org/cpython/rev/8a44e7c0fa30

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan  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 
sandbox - it shares process global state, including the import system, with all 
other modules. While the temporary module will be reverted automatically by 
runpy, any child imports will always remain visible in sys.modules, and any 
other side effects will remain in place (e.g. codec registrations).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Changes by Nick Coghlan :


--
assignee:  -> ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan  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 
you identified in runpy.run_module - names containing "/" characters should be 
rejected as invalid. 

One of the main reasons you're having trouble though is that you can only do 
relative imports when inside a package - at the top level (as both of your 
modules are) relative imports are illegal. By forcing package to "__main__" you 
are claiming a location in the package namespace of "__main__.__main__" which 
doesn't make any sense.

The module life cycle problem for functions is covered in #812369. The only 
reason you're not hitting it in the run_module case is that when "alter_sys" is 
False, no temporary module is created. For data attributes (the intended use 
case for runpy), this all works fine regardless, but functions (which retain a 
reference to the original module namespace) will only work properly with 
alter_sys turned off. There should probably be a general disclaimer in the 
module docs that functions and classes are not guaranteed to be valid after 
using runpy, and importlib.import_module should be used instead for such cases.

#9235 looks into ways the runpy module might be enhanced with a CodeRunner 
class for other reasons, but the same mechanism could be used to keep the 
temporary module alive without storing it in sys.modules.

--
title: runpy.run_path broken: Breaks scoping; pollutes sys.modules; doesn't set 
__package__ -> runpy.run_path doesn't set __package__ correctly

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com