[Python-Dev] Code working in both 2.x and 3.X
Raymond Hettinger wrote: > Also, I'm wondering if the desire for 2.6 warnings is based on the notion that > it will be possible to get large tools to work under both Py2.x and Py3.x. I had certainly assumed it would be possible. In fact, I had assumed that the 2->3 translator would have a mode which left the code running in both. This might not be the cleanest possible code for either line (parens in 2.x, some extra iter calls or missed shortcuts, etc), but it should certainly exist. If it doesn't, then people who do want to support both lines will themselves have to work exclusively in 2.x and "compile" to 3.x. > With all the module renaming/packaging, I had believed that 2.x would support both names, typically as >>> # make an deprecation warning, or log entry >>> from oldname import * So code using the new names may not work in 2.5, but should work in 2.6. If you want it to work in 2.3, you either use conditional imports or include your own forwarding modules for older pythons. > old-style classes disappearing, This is only a problem if you rely on specfically old-style semantics. Most old-style classes that I see work fine as new-style; the author just didn't want to put in the extra boilerplate (or wanted 1.5 compatibility, or just didn't bother to make a change). > encoded text objects, This one I'm less sure about, but it seems that programs which work correctly with both str and unicode in 2.x should work with 3, and that programs which (in practice) restrict themselves to ASCII will continue to work. > real division You can already get this a __future__ import, and you can explicitly request the old form (in both lines) by truncating the result. > and whatnot; that notion may be a pipe-dream. I hope not. That said, I'm not so sure about C extension modules... -jJ ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On 10 Jan, 11:10 pm, [EMAIL PROTECTED] wrote: >On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>I've been assuming for some time that the only hope for Py3k compatibility >>within Twisted would be using PyPy as a translation layer. >Does this ring as many warning bells for me as it does for others? I >know very little about the current state of PyPy, but I read your >comment as implying that you expect Twisted to be unavailable (at some >level or other) for users of Py3K. Is that right? This entirely depends on the migration path available. My understanding of the situation is that Py3K is a different, incompatible language. In that sense, Twisted will only be as unavailable to users of Py3K as it is unavailable to users of Ruby, Perl, or any other dynamic-but-not-Python language. If the 2.x series grows deprecation warnings and gradually has all of py3k's features backported, such that there is a smooth transitional period of a few years where we can support one or two versions of 2.x and a version of 3.x, then eventually perhaps it will be worthwhile. Alternately, if they really aren't compatible *but* there is such a compelling featureset drawing other developers that there's really a critical mass of projects that migrate to 3.x and stop maintaining their 2.x counterparts, it might be worthwhile to jump the chasm to follow them. At a minimum, for it to be worthwhile for Twisted to attempt this if the following packages are all moved to 3.x: - pyopenssl - pygtk - pysqlite - PyObjC - win32all - zope interface (and therefore, probably, all of Zope) - pycrypto - pypam - pygame - pylucene Those projects that do move I'm sure will take the "opportunity" to incompatibly break all of their APIs as well, since no existing code will actually use them, exacerbating the problems involved in porting. ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On Jan 10, 2007, at 6:46 PM, Benji York wrote: > Paul Moore wrote: >> How many other projects/packages anticipate *not* migrating to >> Py3K, I wonder? > > I certainly can't speak for the project as a whole, but I anticipate a > fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0. I (another Twisted developer, among other hats I wear) am also very worried about the Python 3.0 transition. If the goal is really to have Py 3.0 be released later this year, Twisted will almost certainly want to still be compatible with Python 2.4 at that time. (Note that it's currently compatible down to Py 2.3). Even discounting that level of compatibility, it's gonna have to be _at least_ compatible with whatever the latest 2.X release is (2.5, I guess, is the plan?). Due to a lack of manpower, it is also not in all probability a realistic option to maintain two parallel almost-identical development branches, one that supports Python 2.x and one that supports Python 3 [1]. It would be quite a shame if this meant that Twisted effectively cannot move to Python 3.x for years after its release. I don't think anyone wants to see this happen. (and when I say "Twisted" here, I really mean "*every* sizeable python module or program with any current user base whatsoever".) If Python 3.0 was simply a release which removed deprecated features, there would clearly be no issue. I would update my code in advance of the 3.0 release to not use any of those features being removed, and I'm all set. But that's not what I'm hearing. Python 3 is both adding new ways to do things, and removing the older way, in the same version, with no overlap. This makes me very anxious. Basically: my plea is: please don't remove the old way of doing things in Py 3.0 at the same time as you add the new way of doing things. Have a couple versions of compatibility, just for me (and the other thousands of people in the same situation). Please do make the language better, and please do remove huge swaths of old deprecated APIs and functionality. Just, please don't gratuitously remove an old API to make Python a tiny bit cleaner, when there's not already something I can reasonably do *today* to replace it. The dict.keys() change is a simple illustrative case. Here's the situation as I understand it: In Python 2.X, if I want an iterator of items, I call d.iteritems(). d.items() returns a list. In Python 3.X, if I want a iterator (or maybe an set-view; doesn't matter to me) of items, I call d.items(). There is no d.iteritems() I'm completely positive about the change to make d.items() not return a list. It's a great thing to do. But note that there is NOTHING [2] I can call in order to get an iterator of items on both versions! If I want my code to work properly on both, I'll have to write a wrapper function that depends on the python version, like: if py3k: def dict_iteritems(d): return d.items() else: def dict_iteritems(d): return d.iteritems() Clearly this is one of the simplest possible wrappers to write, but It's going to make code really ugly to have to use wrapper functions everywhere instead of methods. My point: is it *truly* necessary to completely remove .iteritems() in the same release that .items() gets iterator behavior? It would make every 3rd party developers' life so much easier if iteritems() stuck around a for another few releases after 3.X gains traction, and I really can't see any downside. Of course, this is only one simple example, and if this was the _only_ incompatible change in Py3k, it would be non-ideal, but not a huge problem. But this same point goes for every single change. All the bidirectionally-incompatible changes put together may very well turn into one huge problem. James [1] Unless of course there's a perfect automated conversion script that can generate the 3.X compatible source code from the 2.X compatible source code. But since such a script is basically impossible, I doubt that's going to be the case. Feel free to prove me wrong here, of course. (but if it is possible, simply build it into python 3.0 so that it can convert old modules at load time and make everyone happy!) [2] iter(d.items()) _does not count_. That is unacceptable on Python 2.X due to the overhead of making the huge list. ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
James Y Knight schrieb: > If Python 3.0 was simply a release which removed deprecated features, > there would clearly be no issue. I would update my code in advance of > the 3.0 release to not use any of those features being removed, and > I'm all set. But that's not what I'm hearing. Python 3 is both adding > new ways to do things, and removing the older way, in the same > version, with no overlap. This makes me very anxious. It has always been planned that in those cases that allow it, the new way to do it will be introduced in a 2.x release too, and the old way removed only in 3.x. Georg ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On 1/11/07, James Y Knight <[EMAIL PROTECTED]> wrote: > If the goal is really to have Py 3.0 be released later this year, 3.0 alpha is scheduled for this year. 3.0 final is not scheduled till next year, and of course another level of tweaks will have to be made after it's been in the Real World for a few months, so it won't fully stabilize until 3.1 or 3.2. That gives 1 1/2 - 2 years if you want to target "production-level" 3.1. Also, major parts of the 3.0 core have not been written yet, so it remains to be seen how realistic the schedule is (or how radical the changes will be if the schedule is kept). There will certainly be demand for an asynchronous server in 3.0, along with the large set of protocols support in Twisted. So either Twisted will be ported or a new package will be written, possibly by some of the Twisted developers, and very likely modelled after Twisted even if the literal code can't be copied. > Due to a lack of manpower, it is also not in all probability a > realistic option to maintain two parallel almost-identical > development branches, So the two projects will operate independently, and the 3.0 one may be smaller and less ambitious than Twisted. But if the need is there it will be written. > Just, please don't gratuitously remove an old > API to make Python a tiny bit cleaner, when there's not already > something I can reasonably do *today* to replace it. How did Perl 4 and Perl 5 handle the situation? I basically waited 2-3 years after Perl 5 came out, then started programming the new way. If it mattered (it didn't), I would have tied my applications specifically to Perl 4. -- Mike Orr <[EMAIL PROTECTED]> ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
Mike Orr wrote: [...] > > How did Perl 4 and Perl 5 handle the situation? I basically waited > 2-3 years after Perl 5 came out, then started programming the new way. > If it mattered (it didn't), I would have tied my applications > specifically to Perl 4. > It's probably a good job you aren't holding your breath for Perl 6, though, eh? How *do* we make it easy for the authors of significant code bases to migrate to 3.0 *and* continue to support hte 2.X "market"? These questions are all very important. I only wish I were serious enough to discuss them ;-). regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
Hi Paul, On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote: > How many other projects/packages anticipate *not* migrating to Py3K, I wonder? FWIW: Psyco. Armin ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
Armin Rigo schrieb: > Hi Paul, > > On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote: >> How many other projects/packages anticipate *not* migrating to Py3K, I >> wonder? > > FWIW: Psyco. What will PyPy do? It will certainly support compiling Py3k code at some point, but will the codebase itself be converted? Georg ___ 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
Re: [Python-Dev] [Python-3000] Code working in both 2.x and 3.X
On 1/11/07, Ron Adam <[EMAIL PROTECTED]> wrote: > Jim Jewett wrote: > > Raymond Hettinger wrote: > > > >> Also, I'm wondering if the desire for 2.6 warnings is based on the notion > >> that > >> it will be possible to get large tools to work under both Py2.x and Py3.x. > > > > I had certainly assumed it would be possible. > > > > In fact, I had assumed that the 2->3 translator would have a mode > > which left the code running in both. > > > > This might not be the cleanest possible code for either line (parens > > in 2.x, some extra iter calls or missed shortcuts, etc), but it should > > certainly exist. If it doesn't, then people who do want to support > > both lines will themselves have to work exclusively in 2.x and > > "compile" to 3.x. > > > >> With all the module renaming/packaging, > [etc... clipped to shorten] > > There seems to be a fair amount of anxiety starting to appear about the > difficulty of trying to support both 2.x and 3.x at the same time. It's > understandable, but I think it may be the earlier than expected 3.0 release > date > that is adding to that. > > Would it be reasonable to define X.0.X versions as official transition > versions > which need not have both back word compatibility, or overly strict future > compatibility? > > I thinking that the 3.0.X version be considered a try it out (alpha) release > to > generate plenty of feed back, and the 3.1.X version be the first version meant > for actual development use. > > 3.0.X <=> 3.alpha.X > 3.1.X <=> 3.first.X > > So the release order may be 3.0.0, 2.6.0, 3.1.0. ... > > (With minor bug fix releases in between, of course.) > > My thinking is developers won't need to support the 3.0.X version *ever*. And > even 3.1.X need not be "too strongly" constrained to be back word compatible > with version 3.0.X, as it may still have quite a few changes. Version 3.1.0 > would then be the first version that future, 3.(1+n), versions will need to > maintain back words compatibility with. > > This gives a lot more time for developers to try it, give feed back, and work > out how to do things like move stuff from 2.X to 3.X, etc... It also may give > more freedom to make changes in version 3.0 with less anxiety to third party > developers. > > Version 3.0 -> a (relatively) clean start with big changes. > > Version 2.6 -> may take into account things in version 3.0. > > Version 3.1 -> builds on 3.0 and may take into account version 2.6 This last line is news to me, and I'm not in favor of it. My plans for 3.1 are different -- to take into account user feedback on 3.0. > Isn't this the general (informal) context already being considered? -- --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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On Friday 12 January 2007 06:09, James Y Knight wrote: > On Jan 10, 2007, at 6:46 PM, Benji York wrote: > > Paul Moore wrote: > >> How many other projects/packages anticipate *not* migrating to > >> Py3K, I wonder? > > > > I certainly can't speak for the project as a whole, but I > > anticipate a fair bit of work to port Zope 3 (100+ KLOC) to > > Python 3.0. > > I (another Twisted developer, among other hats I wear) am also > very worried about the Python 3.0 transition. I'm plan to try and make the transition as painless as possible. A goal I have is to try and make it possible to write code that works in both 2.6 and 3.0. Obviously 2.6 will be backwards-compatible with previous versions, but I'd like to see it get either a command line option or a from __future__ statement to enable compatibility with 3.0-isms, like the dict.items change. > If the goal is really to have Py 3.0 be released later this year, The goal is to have a first alpha sometime this year - there is absolutely no chance of a 3.0 final this year. > Basically: my plea is: please don't remove the old way of doing > things in Py 3.0 at the same time as you add the new way of doing > things. If there was a way to make 2.6 as compatible as possible with 3.0, would this make life less painful? Obviously there'd have to be breakages in a backwards direction, but I'd hope it would make it easier to go forward. Some things should also be OK to backport to 2.6 - for instance, I can't see an obvious reason why 2.6 can't support "except FooError as oopsie" as an alternate spelling of "except FooError, oopsie". Similarly, where the stdlib has been shuffled around, there should be shims in 2.6 that allow people to work with the new names. I don't think waiting for 2.7 to make the compatibility work is a workable approach - we're something like 2.5-3 years away from a 2.7 release, and (optimistically) 12-18 months from a 3.0 final. That leaves a window of 1.5-2 years where we are missing an important tool for people. > [1] Unless of course there's a perfect automated conversion > script that can generate the 3.X compatible source code from the > 2.X compatible source code. I doubt that the 2to3 script will be perfect, but hopefully it can get most things. I can't see it easily fixing up things like check = mydict.has_key ... if check(foo): This is why I also want to add Py3kDeprecationWarning to 2.6. On that note, I'd like to see changes like the mass-change to the stdlib in the 3.0 branch that changed raise A, B into raise A(B) applied to the trunk. This makes it much easier to apply patches to both the 3.0 branch and the trunk. Similar changes should be applied to remove, for instance, use of <> and dict.has_key from the stdlib. Simply put, I'd like the stdlib between 2 and 3 to be as similar as possible. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote: > I'm plan to try and make the transition as painless as possible. I'm glad to hear it. > The goal is to have a first alpha sometime this year - there is > absolutely no chance of a 3.0 final this year. Duly noted. >> Basically: my plea is: please don't remove the old way of doing >> things in Py 3.0 at the same time as you add the new way of doing >> things. > > If there was a way to make 2.6 as compatible as possible with 3.0, > would this make life less painful? At the risk of repeating myself: it's *all* about the overlap between a new way of doing things being added and the previous way being deleted. The overlap that's important here isn't necessarily version numbers, but *time*. Time- since-release correlates directly with the installed userbase of a version of python. I'm supposing the plan is for a nearly- simultaneous 2.6 & 3.0 release (true?). Then, it doesn't really even matter if 2.6 achieves perfect forward compatibility with 3.0, it's too late. 3.0 is out, and if I want to be compatible with it, I'd then have to then require 2.6+. But as 2.6 was just released, I can't require it: most people won't have it installed, and abandoning those users is simply not an option. I need *time* between the addition of the new API and the deletion of the old. When Python 3.0 is released, unless it comes with prominent warnings saying "nobody should actually use this, don't try to make your code run on it, if you run this program all your friends will laugh at you.", early adopter users are going to want to use 3rd party software with Python 3.0. If my only choice at that point is to tell these people "sorry, no, it's simply impossible to support Python 3.0 with a reasonable amount of effort, while still keeping compatible with older Pythons that most users still have", that is not a happy situation. I'd like to avoid this situation. Of course, if 2.6 really is going to be practically identical to 3.0, except that 3.0 will have removed a bunch of functionality, well, then there's absolutely no reason for *anyone* to use 3.0: the only major difference is that nothing can run on it. If that's how things will be, is there even any point in releasing 3.0? What good is it? > Obviously there'd have to be breakages in a backwards direction, I fail to see why this is obvious. Can't 3.0 be content with only removing syntax/features/APIs which can already be replaced by using a newer, better thing that already exists in Python 2.4? There's plenty of that to do! Py 3.0 can also deprecate a whole new pile of stuff to be removed in 3.2, and add a bunch of awesome new features. That's great, no objection. But *some* time between addition of new feature and removal of old feature, please? > I don't think waiting for 2.7 to make the compatibility work is a > workable approach - Well, yes, that would, of course, be even worse. > On that note, I'd like to see changes like the mass-change to the > stdlib in the 3.0 branch that changed raise A, B into raise A(B) > applied to the trunk. This makes it much easier to apply patches to > both the 3.0 branch and the trunk. Similar changes should be > applied to remove, for instance, use of <> and dict.has_key from > the stdlib. Simply put, I'd like the stdlib between 2 and 3 to be > as similar as possible. This suggests an intriguing idea: require all the high level modules in the stdlib in python 3.0 to continue to be compatible with Python 2.5. If the developers of python are forced to make their own code also work with both 2.5 and 3.0, I think any poorly conceived bidirectionally-incompatible changes will be quickly rejected. :) 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
Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On Thursday 11 January 2007 05:13, Raymond Hettinger wrote: > It is my strong preference that we not go down this path. > Instead, the 2.6 vs 3.0 difference analysis should go in an > external lint utility. I don't see how an external utility can possibly catch everything that's going to break - it's going to be much much easier to catch things like use of has_key and the like from inside the interpreter. Additionally, catching things like C code extensions using a slot or a method or a function that's going away is just not going to be possible otherwise. > The Py2.x series may live-on for some time and should do so > as if Py3.x did not exist. Burdening the 2.x code with loads > of warnings will only clutter the source code and make > maintenance more difficult. There may also be some performance > impact. If it's a single check of a C int, the performance impact will be minimal. I agree that 2.x will live for a long time - but unless we provide the best possible upgrade path, we will be stuck maintaining both 2.x and 3.x for ever. Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a new language, having to build a new userbase from scratch. Worse yet, 2.x will suffer as people have the perception "Python 2? That's a dead/abandoned language" > We should resolve that Py2.6 remain as clean as possible > and that Py3.0 be kept in its own world. Forging a new > blade does not have to entail dulling the trusty old blade. I completely disagree here. We cannot simply ignore 3.0 in the 2.x series. We need to provide (as much as possible) an upgrade path for people who write and use code in the language. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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
