On 1/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [A.M. Kuchling] > > 2.6 wouldn't go changing existing APIs to begin requiring or returning > > the bytes type[*], of course, but extensions and new modules might use > > it. > > The premise is dubious. > > If I am currently maintaining a module, why would I switch to a bytes type > and forgo compatibility with Py2.5 and prior? I might as well just convert > it to run on Py3.0 and leave my Py2.5 code as-is for people who want to > run 2.x. > > If I'm writing a new module, what's the point of twisting myself into knots > to get it to run on both Py2.6 and Py3.0? That just makes coding harder > (by limiting me to the intersection of the feature sets). > > I think we should draw a line in the sand and resolve not to garbage-up Py2.6. > The whole Py3.0 project is about eliminating cruft and being free of the > bonds of backwards compatibility. Adding non-essential cruft to Py2.6 > goes against that philosophy.
I'm not so sure, since 2.6 will likely be out and stable long before 3.0 gains much of a foothold. I believe the experiences with a similar approach in the Zope world for the 2->3 transition was overall a favorable one. However, I'd be loathe to make any compromises in 3.0 in order to make life easier for 2.6. The burden must be on 2.6 (and 2.7-2.9), and if it's just impossible, that's too bad for them. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
