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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com