REQUIRING Python 2.1??
[ First of all, I wish people (including Digicoolers) would title their messages descriptively, not just say "Important notice" or whatever. I'm sure many of us consider our words important :) ] Second, I am MYSTIFIED (there's no better word) that DC is in such a rush to REQUIRE the use of Python 2.1 for Zope 2.4, when we're still waiting for Py 2.1 final to even come out. Why put all your eggs in that basket, and why force the community to choose between changing to a bleeding-edge Python or retiring to a frozen Zope rev? Does DC not realize that Python has OTHER applications besides Zope? and that for a given community site, changing Pythons might have unexpected side effects in systems whose developers are less gung-ho about rushing to 2.1 than DC is? I thought I'd set my mind at ease by reading the wiki Brian referred to -- which is called "SupportPython21" although it should apparently have been named "RequirePython21" -- but all I could glean from their justifications was [1] it'll make i18n easier (wow, that's huge), [2] there's some other things with strings and such that "may" be useful, and [3] of course there's a raft of other potentially disruptive differences, but hey, at least we found a way to make i18n easier! I can't quite help wondering whether someone at DC has maybe gotten so "into" the development of Py 2.1 that they just can't wait to use its new stuff, whether it's objectively what's best for Zope or not. The prudent thing to do would have been to add features as needed using 1.5.2-compatible code, or at best to offer a "new18n" branch that requires 2.1, which people who are THAT desperate for i18n could choose to follow if they wanted. Then, say 6-12 months after 2.1 is gold, you could unify and require it for 3.0. Instead, for the sake of being able to let the Python developers stick a Zope logo on the 2.1 release, we are risking a boatload of trouble. On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway. That gives me a thought - anyone for "Rope"? :)
Second, I am MYSTIFIED (there's no better word) that DC is in such a rush to REQUIRE the use of Python 2.1 for Zope 2.4, when we're still waiting for Py 2.1 final to even come out. Why put all your eggs in that basket, and why force the community to choose between changing to a bleeding-edge Python or retiring to a frozen Zope rev?
Does DC not realize that Python has OTHER applications besides Zope? and that for a given community site, changing Pythons might have unexpected side effects in systems whose developers are less gung-ho about rushing to 2.1 than DC is?
You may have more than one Python installation on a machine. This in no way forces you to move "all of your applications" to 2.1. The binary releases in particular make this drop-dead easy; they come with a bundled Python, and do not affect any other Python you may have in any way.
I thought I'd set my mind at ease by reading the wiki Brian referred to -- which is called "SupportPython21" although it should apparently have been named "RequirePython21" -- but all I could glean from their justifications was [1] it'll make i18n easier (wow, that's huge), [2] there's some other things with strings and such that "may" be useful, and [3] of course there's a raft of other potentially disruptive differences, but hey, at least we found a way to make i18n easier!
You've correctly pointed out that I have not captured all of the reasoning. I'll try to correct that in the project docs. And note that Zope is a pretty diverse community - just because i18n is not very important to _you_ does not mean it is not important. There are plenty who consider it hugely significant, and who are at least as perturbed that we _haven't_ done this yet.
Instead, for the sake of being able to let the Python developers stick a Zope logo on the 2.1 release, we are risking a boatload of trouble.
I'm curious where you came up with that assertion - the PythonLabs guys have had absolutely nothing to do with this.
On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway.
You may find that making your objections in a less inflammatory way will give them more impact. We are all for public debate - that is why we are doing this in the open, in a public project area on dev.zope.org. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
[anser] I can't quite help wondering whether someone at DC has maybe gotten so "into" the development of Py 2.1 that they just can't wait to use its new stuff, whether it's objectively what's best for Zope or not. The prudent thing to do would have been to add features as needed using 1.5.2-compatible code, or at best to offer a "new18n" branch that requires 2.1, which people who are THAT desperate for i18n could choose to follow if they wanted. Then, say 6-12 months after 2.1 is gold, you could unify and require it for 3.0. Instead, for the sake of being able to let the Python developers stick a Zope logo on the 2.1 release, we are risking a boatload of trouble. [albert] As far as I can make out the strategy you advocate is more or less exactly what they *did* do - so smoothly you didn't even notice. The *big* leap is from 1.5.2 to 2.0 which has been out for quite a while. I18N is *desperately* needed but had to be delayed because of the compatability problems you are rightly concerned about. So even after I18N became feasible with 2.0 the main branch was made compatible with using 2.0 but binaries released with 1.5.2 to avoid risking a boatload of trouble while enabling people desperate for I18N to start using 2.0 and at the same time discover as much as possible of the hiccups before general switchover. Waiting for the "odd numbered release" is also a generally sound policy. Essentially you are confusing that prudent delay in completing the smoothly planned (and very clearly announced long ago) switch from 1.5.2 to 2.x with a sudden rush to 2.1. Whatever problems do occur will be overwhelmingly from the 2.x, not from it being 2.1 in particular.
If what Albert says is true, then Zope 2.4 should REQUIRE Py 2.0 and SUPPORT Py 2.1, not REQUIRE Py 2.1. --On Saturday, April 14, 2001 1:14 AM +1000 Albert Langer <Albert.Langer@Directory-Designs.org> wrote:
The *big* leap is from 1.5.2 to 2.0 which has been out for quite a while. I18N is *desperately* needed but had to be delayed because of the compatability problems you are rightly concerned about. So even after I18N became feasible with 2.0 the main branch was made compatible with using 2.0 but binaries released with 1.5.2 to avoid risking a boatload of trouble while enabling people desperate for I18N to start using 2.0 and at the same time discover as much as possible of the hiccups before general switchover.
Waiting for the "odd numbered release" is also a generally sound policy. Essentially you are confusing that prudent delay in completing the smoothly planned (and very clearly announced long ago) switch from 1.5.2 to 2.x with a sudden rush to 2.1. Whatever problems do occur will be overwhelmingly from the 2.x, not from it being 2.1 in particular.
On Fri, 13 Apr 2001, Tom Neff wrote:
If what Albert says is true, then Zope 2.4 should REQUIRE Py 2.0 and SUPPORT Py 2.1, not REQUIRE Py 2.1.
But note what he said about "odd numbered releases". True to form, 2.0 adds a whole load of features, and 2.1 cleans up after 2.0. ;-) True, there is a 2.0.1 bugfix-only release of 2.0 due out, which puts some of the 2.1 fixes back into 2.0, but it's probably going to be a lot simpler just to (at least officialy) support 2.1 . I think this probably has a lot more to do with Python's more rapid release schedule since moving to SourceForge, than it does to someone at DC being unable to wait. At the older, more leisurely release non-schedule, 2.1 would probably have been the 2.0.1 release: at the current pace, Python is lapping itself! -- Steve Majewski
On the basis of prior performance I do not expect this objection to make any difference in what DC does, but I needed to express it anyway.
Hey give DC a break! I think people keep forgetting this is a free open source product and they have strived to do everything they can to improve Zope, make a good businness out of it and listen to us whine at the same time. I find DC receptive to things I ask about and they just dont have the time and money to do everything we want. The fishbowl process is a great example of how DC clearly involves the community in upcoming changes. I do not know what "prior performance" you were talking about, but if its with emails like this, Im not surprised. Anyway I full agree 1.5.2 -> 2.0 will be 99% of the pain for Brian. -- Andy McKay
participants (6)
-
Albert Langer -
Andy McKay -
anser -
Brian Lloyd -
Steven D. Majewski -
Tom Neff