[Import-SIG] PEP 395 (Module aliasing) and the namespace PEPs

Nick Coghlan ncoghlan at gmail.com
Thu Nov 17 08:00:00 CET 2011


On Thu, Nov 17, 2011 at 3:48 PM, PJ Eby <pje at telecommunity.com> wrote:
> I'm all in favor of warning or erroring out on aliasing __main__ or relative
> imports from __main__.  It's silently *succeeding* in doing something that
> might not have been intended on the basis of coincidental __init__.py
> placement that I have an issue with.

This is the part I don't get - you say potentially unintentional
success is bad, but you're ok with silently succeeding by *ignoring*
the presence of an __init__.py file and hence performing implicit
relative imports, exactly the behaviour that PEP 328 set out to
eliminate.

Currently, by default, a *correct* package layout breaks under direct
execution. I am proposing that we make it work by preventing implicit
relative imports from __main__, just as we do from any other module.

As a consequence, scripts that already support direct execution from
inside a package would need to be updated to use explicit relative
imports in Python 3.3+, since their implicit relative imports will
break, just as they already do when you attempt to import such a
module. I'm happy to fix things for novices and put the burden of a
workaround on the people that know what they're doing.

The workaround:

    if __name__ == "__main__" and sys.version_info < (3, 3):
        import peer # Implicit relative import
    else:
        from . import peer # explicit relative import

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Import-SIG mailing list