[Python-ideas] PEP for executing a module in a package containing relative imports
jimjjewett at gmail.com
Sun Apr 22 00:03:03 CEST 2007
On 4/20/07, Brett Cannon <brett at python.org> wrote:
> 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:
> > > > 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.
If the code is still using a __main__ variable of its own, then
presumably it isn't using the new meaning of __main__, and isn't
affected by the unexpected semantics.
Or are you concerned that some code *outside* a module could check to
see whether that module is __main__?
> > 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.
In that case, the module itself isn't using (and doesn't care) about
the new __main__ semantics. Code external to the module can't rely on
either (list or __main__) being unchanged, even today.
> > 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.
To me, this is a fairly important requirement that I fear is sometimes
2to3 isn't really a one-time translation unless you stop supporting
2.x after running it.
More information about the Python-ideas