On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:

...

The benefit (to me, and to many others) of 3.x over 2.x is the promise of getting rid of cruft. If we're going to re-add cruft for the sake of temporary compatibility, we may as well just stick with 2.x. You have to take a quantum leap sometimes or you end up working around the same old mistakes.

There seems to be rather a lot of confusion. No one is suggesting Python 3.0 be anything less for the sake of backward compatibility. Instead, it has been suggested Python 2.6 (and possibly 2.7) be something *more* in order to provide for an easier upgrade path. No compromises in Python 3.0.

True: nobody is suggesting python 3.0 be anything less. But, I am indeed suggesting that Python 3.0 be something *more*: I am suggesting that people keep in mind the ease of writing of a program which can run on both 2.5 and 3.0. And wherever possible, act so as to preserve that ease. That may indeed involve a "compromise" in 3.0. Given that Python 3.0 is supposed to be released in ~ 1.5 years (I guess), around the same time as the 2.6 release, I do think 3.0 ought to have a compatibility story that doesn't depend on 2.6. My goal here is not to get Py3.0 to be backwards compatible, it's to get the intersection of 2.5 and 3.0 to be large enough that I can explicitly write code to that intersection without having to tear my hair out and make the code incredibly gross (or worse yet, not be able to do it at all). See previous iteritems() example. I really don't see why there's such an urgency for removing things IMMEDIATELY in Python 3 that don't have a suitable replacement in an already released version. There's plenty to remove which already does have a suitable replacement. I think the major cruft all falls into this category (unicode strings already exist, newstyle classes already exist, non-string exceptions already exist. The 'bytes' type doesn't exist yet, but I expect can be introduced in such a way that it has a useful intersection of functionality with the current method of using 'str' to hold bytes.) I'd like to remind everyone that 3.0 won't be the last version of python ever released (at least, I hope!). Where Py 3.0 introduces a brand-new way to do something, the old can be removed at a future date. Mark it as deprecated, so that nobody will use it in new code, and remove it a few more versions down the line. Getting rid of cruft is great...but you can't properly call something "cruft" when it's the only way. Allowances for writing portable code could make a big difference in speed of adoption. I expect Python 3.0 will be a "quantum leap", even if people don't have to rewrite everything from scratch or fork their codebases to keep compatibility with both releases. There's plenty to look forward to, and I'd love to actually be able to actually use it. But I need to be able to run 3rd party libraries, and the 3rd party libraries must still remain compatible with earlier releases. If those requirements are incompatible with using Py 3.0, it'll be a shame. James

On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:

I'm not keen on compromises in 3.0, but without specific proposals I don't see why we're arguing. So, please, what specific thing(s) are you proposing we do in 3.0? Please make a list of specifics rather than attempting at specifying a general rule to match things that could go into the list; you've tried the latter and I still don't know what you want.

I can't come up with a full list, as I don't know everything that's changed or is being planned to change. But here's some stuff I do know about: 1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys 2) For the bytes type, keep enough of an overlap with the current use of str-as-raw-bytes that common operations work with either one (so that I can, f.e. read from a socket or a file and process that data). Without seeing the details for how bytes is going to be implemented, it's hard to say exactly what this means. 3) Preferably continue to allow old syntax when adding new syntax (e.g. exception catching syntax). Alternatively, a completely reliable automated conversion script to convert the syntax would also be acceptable if not quite as convenient. Mainly I'd just like to see "allowing the ability to write code which is portable between 2.5 and 3.0" as an explicit goal of the python 3.0 release. I trust that if the developers agree upon that as being a goal, the right things would happen, whatever they may be for the specific change in question. James

On 1/16/07, James Y Knight wrote:

On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:

...

I'm not keen on compromises in 3.0, but without specific proposals I don't see why we're arguing. So, please, what specific thing(s) are you proposing we do in 3.0? Please make a list of specifics rather than attempting at specifying a general rule to match things that could go into the list; you've tried the latter and I still don't know what you want.

I can't come up with a full list, as I don't know everything that's changed or is being planned to change. But here's some stuff I do know about:

1) don't remove dict.iteritems, dict.itervalues, dict.iterkeys 2) For the bytes type, keep enough of an overlap with the current use of str-as-raw-bytes that common operations work with either one (so that I can, f.e. read from a socket or a file and process that data). Without seeing the details for how bytes is going to be implemented, it's hard to say exactly what this means. 3) Preferably continue to allow old syntax when adding new syntax (e.g. exception catching syntax). Alternatively, a completely reliable automated conversion script to convert the syntax would also be acceptable if not quite as convenient.

Mainly I'd just like to see "allowing the ability to write code which is portable between 2.5 and 3.0" as an explicit goal of the python 3.0 release. I trust that if the developers agree upon that as being a goal, the right things would happen, whatever they may be for the specific change in question.

Well, there's the crux. That is an explicit NON-goal. It always has been. It would add tons of constraints to Python 3000, and the net effect would be that everybody would continue to code in the 2.5 dialect, making the intended cleanup of the language ineffective. We are planning various other ways of providing conversion help. The most promising at this point is to make the following an explicit goal of Python 2.6 and Python 3000: make it possible to write code that runs under 2.6, and that, after automatic conversion using the 2to3 refactoring tool (see sandbox/2to3), runs under 3.0, *without* requiring manual patching up of the output of the refactoring tool. The latter clause makes it easy (if not trivial) for developers to maintain parallel versions. All you need is a sufficiently good test suite, so that you can automatically verify that the conversion result actually works as intended under 3.0. Since you'd have to do that testing anyway, there is not much of an added effort except for maintaining separate tarballs. There are still certain things you can't do, because the conversion tool doesn't handle them well (e.g. don't use variables named 'long' and don't create classes with methods named 'keys'); but I expect that the subset of 2.6 that you can use will be much larger using this approach than what you would get using the identical-source approach you are supporting. Oh, and the same approach will also work (with only a few more constraints) for 2.5 and even earlier versions. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

"James Y Knight" wrote in message news:1C852710-575A-4855-8460-F70E74D57192@fuhm.net... | Everyone will continue to code in a | 2.5-compatible dialect for the immediate future, because their code | needs to continue to function in 2.5. ?? But once 2.6 and 3.0 come out, there will be some to many who don't have that need. Anyone who needs their code to function in x.y will have to restrict their code to x.y and not use future additions. And people who don't, may use new features. Nothing new here. I expect that if Guido survives and continues with the Py3 series, then in 10 years, at least half of Python programmers will be essentially Py3 only, either by switching and not looking back or by having learned on Py3. | As I keep pointing out, the | language cleanup doesn't have to be all at once: Of course, and gradual, continual cleanup was the original policy: deprecate, warn, and then remove. But several years ago, enough people complained that Guido said "Ok, we will put non-trivial removals off for several years and then do it all at once in a new 3.0 version." Under the old policy, apply(), old int division (1/2 ==0 instead of .5), and probably some others would have been long gone. Now several years is about here. Terry Jan Reedy