Mailman 3 January 2007 - Python-Dev

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com 12 Jan '07

12 Jan '07

On 09:04 pm, tcdelaney(a)optusnet.com.au wrote: >I'm wondering if we might be going the wrong way about warning about >compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0 >alpha had a 2.x compatibility mode command-line flag, which is removed late >in the beta cycle. Please, no. I don't think command-line flags are going to help much, because the problem is not the complexity of downloading and compiling py3k, it is the complexity of porting software that has modules from a variety of different sources. More importantly however, I'm not even going to be looking into porting anything to py3k until a year or so after its release - and that's only if 2.6 has given me some tools to deal with the transition. The reason I am posting to this thread is that I had *written off py3k entirely* before Anthony started making noises about forward compatibility. The support cycle of Ubuntu Dapper makes it likely that Twisted will be supporting Python 2.4 until at least 2011. I assume 2.5 will last a year after that, so assuming 2.6 has perfect forward compatibility, we'll be looking at a py3k port in early 2013. Features available in the beta releases aren't going to help me there. Plus, this defeats the whole purpose of py3k. Why break compatibility if you're going to include a bunch of gross compatibility code? Compatibility has already been broken in the py3k branch, there's no point in putting it back there. Adding it to 2.x might make sense though.

1 0

Re: [Python-Dev] Code working in both 2.x and 3.X
by Facundo Batista 12 Jan '07

12 Jan '07

Ron Adam wrote: > 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. +1 for this approach. I think it's very clear, and everybody will understand it (ok, not everybody, we know people...). -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

2 1

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by Phillip J. Eby 12 Jan '07

12 Jan '07

At 11:59 AM 1/12/2007 +0000, glyph(a)divmod.com wrote: >In order to do this, everything that has been changed in 3.0 has to have >some mechanism for working both ways in some 2.x release. I phrased this >as its "feature set" because I am not aware of any new functionality in >3.0 that simply isn't available 2.x - everything I've seen are "cleanups", >which expose basically the same features as 2.5. > >If there are some real new features, then I am in error. If I understand correctly, argument annotations, and exceptions having traceback attributes are new features.

1 0

trunk changes not suited for 3.0
by Georg Brandl 12 Jan '07

12 Jan '07

Hi, currently, changes in the trunk are merged to the p3yk branch. What about changes such as the discussed -3 warn option, or __future__ imports for stuff that'll be in 3k anyway? Can/should these revisions just be excluded from the merge? Or would it be better to apply them to a new branch? Georg

3 2

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com 12 Jan '07

12 Jan '07

On 11:22 am, anthony(a)interlink.com.au wrote: >> FWIW, I also agree with James that Python 3 shouldn't even be >> released until the 2.x series has reached parity with its feature >> set. However, if there's continuity in the version numbers >> instead of the release dates, I can at least explain to Twisted >> users that we will _pretend_ they are released in the order of >> their versions. > >I'm not sure what "parity with it's feature set" means. I don't either! "Parity with it is feature set"? I can't even parse that! ;-) By "parity with *its* feature set", though, I meant what you said here: >I do hope that it's _possible_ to work in a version of the language that works in both 2.6+ and 3.0+, even if under the hood there are differences. In order to do this, everything that has been changed in 3.0 has to have some mechanism for working both ways in some 2.x release. I phrased this as its "feature set" because I am not aware of any new functionality in 3.0 that simply isn't available 2.x - everything I've seen are "cleanups", which expose basically the same features as 2.5. If there are some real new features, then I am in error.

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com 12 Jan '07

12 Jan '07

On 07:56 am, anthony(a)interlink.com.au wrote: >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" It's worse than that. This perception has _already_ been created. I already have heard a few folks looking for new languages to learn choose Ruby over Python and give Py3K as a reason. "Isn't Python going to be totally different in a few years anyway? I'll just wait until then, seems like a waste of time to learn it now." Given Ruby's own checkered history of compatibility, I don't think this is an _accurate_ perception, but it is the nature of perception to be inaccurate. If the plan is to provide a smooth transition, it would help a lot to have this plan of foward and backward compatibility documented somewhere very public. It's hard to find information on Py3K right now, even if you know your way around the universe of PEPs. FWIW, I also agree with James that Python 3 shouldn't even be released until the 2.x series has reached parity with its feature set. However, if there's continuity in the version numbers instead of the release dates, I can at least explain to Twisted users that we will _pretend_ they are released in the order of their versions.

2 1

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com 12 Jan '07

12 Jan '07

On 01:12 am, anthony(a)interlink.com.au wrote: >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. This is all very encouraging. Please stick with a __future__ statement if at all possible though. The biggest challenge in migration is to reduce the impact so that it can be done partially in a real system. If you have a module X wants to be "3.0 safe" which imports a module Y from a different developer that is not, command line options for compatibility might not help at all. A __future__ statment in X but not in Y, though, would allow for a smooth transition. I can see how that would be tricky for things like dictionary methods, but it does seem doable. For example, have a has_key descriptor which can raise an AttributeError if the globals() of the calling stack frame has been marked in some way. >> 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". You happen to have hit my favorite hot-button 3.0 issue right there :). I don't care about backticks but sometimes I _do_ have to catch exceptions. >Similarly, where the stdlib has been shuffled around, there should >be shims in 2.6 that allow people to work with the new names. This part I wouldn't even mind having to write myself. It would certainly be good to have somewhere more official though. >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. It would be nice if the versioning would actually happen in order. >> [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): Currently a common idiom, by the way, used throughout the lower levels of Twisted. >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. It would be nice if the stdlib could be used as a case study - if the 3 stdlib tests can pass on some version of 2 (or vice versa) that should be a minimum bar for application portability. Maybe a better way to handle the similarity is that the reorganized stdlib should simply be available as a separate piece of code on 2.x? That would allow 2.x to use any new features added and distinguish between code which had been moved to use new stdlib APIs and that which hadn't.

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by Anthony Baxter 12 Jan '07

12 Jan '07

cc'ing python-dev - followups should probably go there, rather than the p3yk list. So here's my latest plan: - Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning (or maybe just of Warning) - Add a -W py3k shortcut, which is the same as "-W once:Py3kDeprecationWarning" - Add a C int (as in previous patch) that is also set to 1 if the command line flag is specified. This is because there's no easy or quick way to check that a warning has been set - and calling into the warnings code is expensive, even if the C code warnings module is done. We can revisit this if the C version of warnings grows some extra features to make this less awful. For 2.6, we make a single -t (mixing tabs and spaces) the default, and maybe add -T to suppress this. DeprecationWarning for 2.6: - `foo` (backticks) - input() The following are the list of things that get Py3kDeprecationWarnings (so far): integer division - make "-Q warn" the default when -W py3k specified coerce() - going away apply() - going away intern() - moving to sys (we should also move it to sys, and make intern() - call sys.intern()) file.xreadlines() - going away dict.has_key() - use 'in dict' <> - use != (aka "MakeBarryCryDeprecationWarning") __(get|set|del)slice__ __coerce__ - gone __(div|idiv|rdiv)__ - no replacement? __nonzero__ - we should add __bool__ to 2.6, and then warn people. Not sure we can rename the nb_nonzero slot, though. For the various __foo__ slots, it might be nice to warn when they're defined, rather than used, but I've not looked into how hard this would be to do, or whether it would still work with .pyc files and the like. On the other hand, warning on use might also let us pick up when C code modules use the same functions. There's other changes that are probably too hard to warn about, because there's not an easy replacement - the exec and print statements come to mind here. Comments? What else should get warnings? Anthony

9 15

Re: [Python-Dev] [Python-3000] Code working in both 2.x and 3.X
by Guido van Rossum 11 Jan '07

11 Jan '07

On 1/11/07, Ron Adam <rrr(a)ronadam.com> 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/)

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com 11 Jan '07

11 Jan '07

On 10 Jan, 11:10 pm, p.f.moore(a)gmail.com wrote: >On 10/01/07, glyph(a)divmod.com <glyph(a)divmod.com> 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.

1 0