On 4/20/07, Brett Cannon <brett@python.org> wrote:
On 4/20/07, Steven Bethard <steven.bethard@gmail.com> wrote:
On 4/20/07, Brett Cannon <brett@python.org> wrote:
On 4/19/07, Steven Bethard <steven.bethard@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