[Python-ideas] PEP for executing a module in a package containing relative imports
jcarlson at uci.edu
Sun Apr 22 19:39:57 CEST 2007
"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
> # 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.
More information about the Python-ideas