On Friday 12 January 2007 21:42, email@example.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.