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
