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

[Josiah Carlson]

"Jim Jewett" <jimjjewett at gmail.com> wrote:
> 
> On 4/21/07, Brett Cannon <brett at python.org> wrote:
> > On 4/21/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> 
> > > After reading other posts in the thread, I'm going to put my support
> > > into the sys.main variant.  It has all of the benefits of the builtin __name__
> > > == __main__, with none of the drawbacks (no builtin!), and only a slight
> > > annoyance of 'import sys', which is more or less free.
> 
> > Yeah, I am starting to like it as well.  Steven and Jim, what do you think?
> 
> Better than adding a builtin.
> 
> I'm not sure I like the idea of another semi-random object in sys
> either, though.
> 
> (1)  One of the motivations was importing.  It looks like __file__
> already has sufficient information.  I understand that relying on it
> (or on __package__?) seems a bit hacky, but is it really worse than
> adding something?
> 
> (2)  Is there a reason the main module can't appear in sys.modules
> twice, once under the alias "__main__"?

While it is unlikely, there may be cleanup issues when the process is
ending.


> # Equivalent to today
> if __name__ == sys.modules["__main__"].__name__:
> 
> # Better than today
> if __name__ is sys.modules["__main__"].__name__:

The above two should be equivalent unless the importer has a bad habit.


> # What I would like (pending PEP I hope to write tonight)
> if __this_module__ is sys.modules["__main__"]:

While I would also very much like the ability to access *this module*,
I don't believe that this necessarily precludes the use of a proper
package.module naming scheme for all __name__ values.


 - Josiah