PEP 366 implementation

[ncoghlan]

BPO	1487
Nosy	@gvanrossum, @ncoghlan
Files	pep_366_v2.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ncoghlan'
closed_at = <Date 2007-12-03.12:58:01.583>
created_at = <Date 2007-11-22.14:22:16.462>
labels = ['interpreter-core', 'type-feature', 'library']
title = 'PEP 366 implementation'
updated_at = <Date 2007-12-03.12:58:01.582>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2007-12-03.12:58:01.582>
actor = 'ncoghlan'
assignee = 'ncoghlan'
closed = True
closed_date = <Date 2007-12-03.12:58:01.583>
closer = 'ncoghlan'
components = ['Interpreter Core', 'Library (Lib)']
creation = <Date 2007-11-22.14:22:16.462>
creator = 'ncoghlan'
dependencies = []
files = ['8852']
hgrepos = []
issue_num = 1487
keywords = ['patch']
message_count = 6.0
messages = ['57761', '58003', '58080', '58087', '58098', '58120']
nosy_count = 2.0
nosy_names = ['gvanrossum', 'ncoghlan']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1487'
versions = ['Python 2.6', 'Python 3.0']

[ncoghlan]

Patch to implement PEP-366.

Note that it doesn't implement precisely the semantics described in the
version of the PEP posted in July, as some of those ideas didn't prove
feasible due to the fact that imp.new_module can't tell the difference
between normal modules and packages.

An updated version of the PEP will be posted shortly to correct those
problems.

[gvanrossum]

I think the implementation is fine too (others will have to check it
more carefully) but I noticed that the promised functionality of -m
doesn't work yet: I created a file Lib/test/foo.py whose sole contents
was "from . import test_support". Then I tried to import this using
-m:

$ ./python.exe -m test.foo
Traceback (most recent call last):
 File "/Users/guido/p/Lib/runpy.py", line 104, in _run_module_as_main
   "__main__", fname, loader)
 File "/Users/guido/p/Lib/runpy.py", line 34, in _run_code
   exec code in run_globals
 File "/Users/guido/p/Lib/test/foo.py", line 1, in <module>
   from . import test_support
ValueError: Attempted relative import in non-package
$

What's missing here?

[ncoghlan]

I forgot to update the special _run_module_as_main variant when I
modified run_module. I'll modify the patch to fix that and to test '-m'
explicitly in test_cmd_line_script.

[ncoghlan]

Posted v2 of the patch, which fixes the problem Guido noted, and
improved the tests to make sure __package__ is being set correctly.
There's also now an explicit test for using -m on a module inside a
package (which proved harder to write than I expected - it isn't easy to
fiddle with sys.path when the subprocess is running python with the -E
flag!).

[gvanrossum]

Great, now check it in!

On Dec 2, 2007 6:01 AM, Nick Coghlan <report@bugs.python.org> wrote:

Nick Coghlan added the comment:

Posted v2 of the patch, which fixes the problem Guido noted, and
improved the tests to make sure __package__ is being set correctly.
There's also now an explicit test for using -m on a module inside a
package (which proved harder to write than I expected - it isn't easy to
fiddle with sys.path when the subprocess is running python with the -E
flag!).

Added file: http://bugs.python.org/file8852/pep_366_v2.diff

---

Tracker <report@bugs.python.org>
<http://bugs.python.org/issue1487\>

---

[ncoghlan]

Checked in as rev 59288.