[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