On 3/20/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > -0 on separate mailing list and PEP numbers.
You seem to be the minority so far... > Because to much separation between python 2.x and python 3.x makes 3.x > seem more like vaporware that will never happen (Perl 6). I'm actually trying to reenergize things to make sure Python 3000 *will* happen. > I would have > hoped that the transition to 3.x would be evolutionary in small steps; > removal of string exceptions in one major release, replacement of > print with a function in the next and so on. To the extent possible that's certainly the plan. But there are certain changes that are too hard to do without introducing a major incompatibility -- you can't add warnings for everything, especially not where the semantics of an existing API changes (e.g. range(), or dict.keys(), or int/int). Future statements don't help for some of these cases either (especially not for dict.keys() and similar, since dicts are passed between modules). > A total redesign from > bottom up in one release has a very high probability of "failing" > IMHO. There's not going to be a total redesign. This is exactly the kind of misunderstanding that I would like to address by specifying a process for getting there rather than just starting to discuss features. 3.0 will be the opportunity to radically clean up mistakes I made 16 years ago, by allowing the language to change backwards incompatibly. It is *not* intended to be as an invitation to start adding random new ideas. (In fact, there's something to say for *limiting* Python 3000 to the incompatibilities, and to continue introducing new ideas in 2.x, as long as they don't require incompatibilities beyond the occasional new keyword, which can be handled with a warning and a future statement. But that's for the Python 3000 process to be decided.) > Or at least very annoying for end users that who to deal with > two parallel and incompatible versions. Well that can't be helped, really, unless you want to keep the language backwards compatible forever, can it? Some necessary changes *are* incompatible, so they are going to cause some pain during the transition. The alternative would be years and years of pain as various changes are introduced in different versions (if we did it all at once it would *be* Python 3.0 of course :-). Python 3000 hopes to ease the pain by making it all happen at once (ripping the band-aid off quickly, so to speak :-) while at the same time giving users a chance to decide *when* to do it -- since (in my vision, anyway) there will be a fair amount of maintenance applied to the 2.x branch even after 3.0 has been released. > The reality is that > discussions about python 3000 has a high probability of being a total > waste of time. I think all those of us who have for lengths argued > whether lambda should stay or be dropped knows that. :) Now that sounds like an insult. I hope you didn't mean it that way. Discussing Python 3000 will *not* be a waste of time. I fully intend to carry through the changes and release Python 3.0 as I have envisioned it for a long time. If anything's a waste of time, it's discussing random Python 3000 proposals without having a good process in place first. That's what I want to change right now. Barry, if you could create that mailing list, please? -- --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
