Skip to content

PEP 366 implementation #45828

Closed
Closed

Description

@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']

    Activity

    1. ncoghlan commented on Nov 22, 2007

      @ncoghlan
      ContributorAuthor

      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.

    2. added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      stdlibStandard Library Python modules in the Lib/ directory
      type-featureA feature request or enhancement
      on Nov 22, 2007
    3. self-assigned this
      on Nov 30, 2007
    4. gvanrossum commented on Nov 30, 2007

      @gvanrossum
      Member

      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?

    5. ncoghlan commented on Dec 2, 2007

      @ncoghlan
      ContributorAuthor

      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.

    6. ncoghlan commented on Dec 2, 2007

      @ncoghlan
      ContributorAuthor

      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!).

    7. gvanrossum commented on Dec 2, 2007

      @gvanrossum
      Member

      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\>


    8. ncoghlan commented on Dec 3, 2007

      @ncoghlan
      ContributorAuthor

      Checked in as rev 59288.

    9. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions