[Python-Dev] [Python-3000] Warning for 2.6 and greater
Anthony Baxter
anthony at interlink.com.au
Fri Jan 12 12:22:51 CET 2007
On Friday 12 January 2007 21:42, glyph at divmod.com wrote:
> If the plan is to provide a smooth transition, it would help a
> lot to have this plan of foward and backward compatibility
> documented somewhere very public. It's hard to find information
> on Py3K right now, even if you know your way around the universe
> of PEPs.
I'd like to see this happen, too - however, there's no way I can
even think about it until after LCA next week. First of all, of
course, we need to get agreement on the preferred way forward.
> FWIW, I also agree with James that Python 3 shouldn't even be
> released until the 2.x series has reached parity with its feature
> set. However, if there's continuity in the version numbers
> instead of the release dates, I can at least explain to Twisted
> users that we will _pretend_ they are released in the order of
> their versions.
I'm not sure what "parity with it's feature set" means. I think
there's going to be some 3.0isms that just cannot be done sanely in
2.x - for instance, the new I/O subsystem. But I do hope that it's
_possible_ to work in a version of the language that works in both
2.6+ and 3.0+, even if under the hood there are differences. For
instance, if we did "except foo as bar" for 2.6, it might not
auto-clean-up the exception object when it drops out of the except:
block.
I put up www.python.org/sf/1633807 a short time ago that deals with
one of the big concerns I had - print vs print() (it was also as a
learning exercise to figure out if it was possible, and how it
might work). Something similar could probably be done for exec(). I
suspect the problem cases are going to be things like the
dictionary code - your idea (in another email) of trying to look up
globals would probably cause a horrible performance issue, but it
may be possible to do _something_ clever.
Anthony
--
Anthony Baxter <anthony at interlink.com.au>
It's never too late to have a happy childhood.
More information about the Python-Dev
mailing list