On 8/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Specifically his reponse to the "Here's my suggestion:" paragraph. > Unless I completely misunderstood his response, and his later asking > whether I want to help author the transition PEP (presumably for at > least dict.keys(), bur more likely from 2.x to 3.x), I can't help but > believe that he also wants at least an attempt at some gradual change > for users with cold feet about breaking everything in one go. > > Also, in the talk he gave at Google on July 21, somewhere around the > 7:45-11 minute mark, he talks about how 3.x features are to be > backported to 2.7 or so, specifically so that there is a larger subset > of Python that will run in both 2.x and 3.x . Smells like an attempt at > gradual migration to me.
Since you're trying to channel me, and I'm right here listening to you (and annoyed that you are wasting my time), I need to clarify. What I *don't* want to happen is that Python 2.6 2.7, and so on keep changing the language from under users' feet, requiring constant code changes to keep up, so that by the time the 2.9 -> 3.0 transition comes it will feel pretty much the same as 2.4 -> 2.5. That would be bad because it would mean that for every transition users would have to make a lot of changes. (Pretty much the only changes like that planned are increasing deprecation warnings for string exceptions, and making 'with' and 'as' unconditional keywords in 2.6.) 3.0 (or 3.2) will feel like a big change and will require a combination of automatic and manual explicit conversion, sometimes guided by warnings produced by Python 2.x in "future-proof-lint" mode (see (a) below). What I *do* want to do is: (a) Add an option to Python 2.6 or 2.7 that starts spewing out warnings about certain things that will change semantics in 3.0 and are hard to detect by source code inspection alone, just like the current -Q option. This could detect uses of range(), zip() or dict.keys() result values incompatible with the iterators or views that these will return in 3.0. But there will be no pressure to change such code before the 3.0 transition, and those warnings will be off by default. (b) Provide access to the new syntax, without dropping the old syntax, whenever it can be done without introducing new keywords, or through __future__ syntax. But these approaches alone cannot cover all cases. While we can probably backport the new I/O library, there won't be a way to test it in a world where str and unicode are the same (unless your app runs on Jython or IronPython). The str/unicode unification and the int/long unification, taking just two examples, just can't be backported to Python 2.x, since they require pervasive and deep changes to the implementation everywhere. Another change that is unlikely to be available in 2.x is the rationalization of comparisons. In 3.0, "1 < 'abc'" will raise a TypeError; there's just no way to backport this behavior, since again it requires pervasive changes to the implementation. I know that you are dreaming of a world where all transitions are easy. But it's just a dream. 3.0 will require hard work and for many large apps it will take years to migrate -- the best approach is probably to make it coincide with a planned major rewrite of the app. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
