[Python-ideas] PEP for executing a module in a package containing relative imports
brett at python.org
Fri Apr 20 19:11:43 CEST 2007
On 4/20/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> "Brett Cannon" <brett at python.org> wrote:
> > Some of you might remember a discussion that took place on this list
> > about not being able to execute a script contained in a package that
> > used relative imports (read the PEP if you don't quite get what I am
> > talking about). The PEP below proposes a solution (along with a
> > counter-solution).
> > Let me know what you think. I especially want to hear which proposal
> > people prefer; the one in the PEP or the one in the Open Issues
> > section. Plus I wouldn't mind suggestions on a title for this PEP.
> > =)
> About all I can come up with is "Fixing relative imports".
> > if __name__ == '__main__':
> > ...
> > to::
> > if __main__:
> > ...
> According to your PEP, the point of the above is so that __name__ can
> become something descriptive, so that relative imports can do their
> thing as per PEP 328 semantics. However, both of your proposals seek to
> offer a value for __main__ (either as a builtin or module global).
> While others will probably disagree with me, I'm going to go with your
> 'open issues' proposal of ...
> > if __name__ == __main__:
> > ...
Woohoo! It's my preference, but that's just because I think it will
be easier to implement.
> As you say, errors arising from the 'subtle' removal of quotes will be
> quickly discovered (without a 2to3 conversion), and with a 2to3
> conversion can be automatically converted. In 2.6, it could result in a
> warning or exception, depending on how Python 2.6 is run and/or what
> __future__ statements are used. It also doesn't rely on sticking yet
> another value in a module's globals (which makes it easier for 3rd
> parties to handle module loading by hand), while still makeing __main__
That's a good point.
> For people who had previously been using sys.modules['__main__'], they
> can instead use sys.modules[__main__] to get the same effect, which your
> initial proposal does not allow.
More information about the Python-ideas