[Python-ideas] PEP for executing a module in a package containing relative imports (original) (raw)

Brett Cannon brett at python.org
Sat Apr 21 03:35:42 CEST 2007

On 4/20/07, Steven Bethard <steven.bethard at gmail.com> wrote:

On 4/20/07, Brett Cannon <brett at python.org> wrote: > On 4/19/07, Steven Bethard <steven.bethard at gmail.com> wrote: > > On 4/19/07, Brett Cannon <brett at python.org> wrote: > > > Transition Plan > > > =============== > > > > > > Using this solution will not work directly in Python 2.6. Code is > > > dependent upon the semantics of having _name_ set to > > > '_main_'. There is also the issue of pre-existing global > > > variables in a module named _main_. > > > > Could you explain a bit why main couldn't be inserted into modules > > before the module is actually executed? E.g. something like:: > > _> > >>> moduletext = '''_ > > ... main = 'foo' > > ... print main > > ... ''' > > >>> import new > > >>> mod = new.module('mod') > > >>> mod.main = True > > >>> exec moduletext in mod.dict > > foo > > >>> mod.main > > 'foo' > > > > I would have thought that if Python inserted main before any of > > the module contents got exec'd, it would be backwards compatible > > because any use of main would just overwrite the default one. > > That's right, and that is the problem. That would mean if main > was false but then overwritten by a function or something, it suddenly > became true. It isn't a problem in terms of whether the code will > run, but whether the expected semantics will occur.

Sure, but I don't see how it's much different from anyone who writes:: list = [foo, bar, baz] and then later wonders why:: list(obj) gives a TypeError: 'list' object is not callable.

Exactly. It's just that 'list' was known about when the code was written while main was not.

If someone doesn't understand that the main they defined at the beginning of a module is going to be the same main they use at the end of the module, they're going to need to go do some reading about how name binding works in Python anyway.

Of course, I definitely think it would be valuable to have a Py3K deprecation warning to help users identify when they've made a silly mistake like this. (Note that the counter-proposal has the same problem, so this needs to be resolved regardless of which approach gets taken.)

Yep.

I'd really like there to be a way to write Python 3.0 compatible code in Python 2.6 without having to run through 2to3. I think it's clear that main can be defined (at module-level or in the builtins) without introducing any backwards compatibility problems right? Anyone that doesn't want to use the Python 3.0 idiom can still write ``if name == 'main'`` and it will continue to work in Python 2.X. And anyone who does want to use the Python 3.0 idiom is probably using the Py3K flag anyway, so if they make a stupid mistake, it'll get caught pretty quickly.

Exactly. Python 2.6 will still have name set to 'main', but also have main set. Python 3.0 will not change name at all. This is why the PEP is a Py3K PEP and not a 2.6 PEP.

-Brett

More information about the Python-ideas mailing list