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

[Jim Jewett]

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
being forgotten.

2to3 isn't really a one-time translation unless you stop supporting
2.x after running it.

-jJ