[Python-Dev] PEP 366 - Relative imports from main modules

[Brett Cannon]

On 7/8/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Josiah Carlson wrote:
> > "Brett Cannon" <brett at python.org> wrote:
> >> On 7/5/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> >>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote:
> >>>> I see no big problems with this, except I wonder if in the end it
> >>>> wouldn't be better to *always* define __package_name__ instead of only
> >>>> when it's in main? And then perhaps rename it to __package__? Done
> >>>> properly it could always be used for relative imports, rather than
> >>>> parsing __module__ to find the package. Then you won't even need the
> >>>> error handler.
> >>> +1 for __package__, and putting it everywhere.  Relative import
> >>> should use it first if present, falling back to use of __name__.
> >> +1 from me as well.
> >
> > This would solve some issues I'm currently having with relative imports.
> > +1
>
> I've updated the PEP to incorporate the feedback from this thread. The
> new version is below, and should show up on the website shortly.
>
> Cheers,
> Nick.
>
> PEP: 366
> Title: Main module explicit relative imports
> Version: $Revision: 56190 $
> Last-Modified: $Date: 2007-07-08 17:45:46 +1000 (Sun, 08 Jul 2007) $
> Author: Nick Coghlan <ncoghlan at gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-May-2007
> Python-Version: 2.6, 3.0
> Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007
>
>
> Abstract
> ========
>
> This PEP proposes a backwards compatible mechanism that permits
> the use of explicit relative imports from executable modules within
> packages. Such imports currently fail due to an awkward interaction
> between PEP 328 and PEP 338.
>
> By adding a new module level attribute, this PEP allows relative imports
> to work automatically if the module is executed using the ``-m``switch.
> A small amount of boilerplate in the module itself will allow the relative
> imports to work when the file is executed by name.
>
>
> Proposed Change
> ===============
>
> The major proposed change is the introduction of a new module level
> attribute, ``__package__``. When it is present, relative imports will
> be based on this attribute rather than the module ``__name__``
> attribute.
>
> As with the current ``__name__`` attribute, setting ``__package__`` will
> be the responsibility of the PEP 302 loader used to import a module.
> Loaders which use ``imp.new_module()`` to create the module object will
> have the new attribute set automatically to
> ``__name__.rpartition('.')[0]``.

Is this really the best semantics for this?  Let's say I have
A/B/__init__.py and A/B/C.py.  With these semantics I would have A.B
having __package__ be 'A' and A.B.C having 'A.B'.

While I agree that the A.B.C setting is correct, is the A.B value what
is truly desired?  Is an __init__ module really to be considered part
of the above package?  I always viewed the __init__ module as part of
its own package.  Thus I expected A.B to have __package__ set to
'A.B'.

Beyond just what I expected, the reason I bring this up is that if
__package__ had the semantics I am suggesting, it is trivial to
discover what modules are the package __init__ modules (as
``__package__ == __name__``) compared to being a submodule
(``__package__ and __package__ != __name__``).  As of right now you
can only do that if you examine __file__ for __init__.py(c), but that
is highly dependent on how the module was loaded.  It might be nice if
what kind of module (top-level, package, or submodule) something is
based on its metadata.

-Brett