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

Steven Bethard steven.bethard at gmail.com
Sat Apr 21 00:08:16 CEST 2007

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.

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.)

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.

Steve

I'm not in-sane. Indeed, I am so far out of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

More information about the Python-ideas mailing list