[Python-ideas] PEP for executing a module in a package containing relative imports

Josiah Carlson jcarlson at uci.edu
Fri Apr 20 09:16:49 CEST 2007


"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__:
>       ...

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__
accessable.

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.

 - Josiah




More information about the Python-ideas mailing list