Yes these are all fairly painful scenarios. What's worse is the scenario for organizations evaluating zope end user software using python 2. It's will not be a great selling feature to start with the premise that anything you see today will require major refactoring to give provide a measure of 'futureproof' code.

It is also possible that as so long as you are tied to python 2 you may be fighting the impression that you are speeding toward obsolescence. Regardless, I expect this impression to develop outside the python community and formalized as a marketing tool against python applications. This will come into play when it is common knowledge that P3K is stable and virtually all python technology runs on python 2. I can see possible wins here for ruby and java as they will be evaluated without this inherent risk.

Porting will have to come soon; otherwise the risk is loose the ability to market zope. Zope is in the fray with other frameworks in python and other languages. Not seeing a zope emerging in P3K (as it is evolving) is likely going to mean a challenging sell for anyone getting involved with the framework (whether you are a developer or consumer). Consumers need to know their data will survive this potential (think about all those pickles).

A zope 4 on P3K could be an answer (with zope 3 modules being ported as P3K evolves). It could also signal the beginning of coordination efforts with other projects that zope depends upon (and provide a sense of collaboration to address the future). The ZODB would have to be a priority for this. It's ugly, but I think moving through a python 2.5 and then a 2.6 without establishing a parallel track may be perilous. This sort of activity would mean meeting P3K as opposed to inviting the consequences. Personally, relying on conversion scripts from a 2.6 release is not comforting. Subtle changes in the language are already being discussed and it will not solve the issue of extensions that has already been raised.

P3K has the potential to disrupt zope and its marketing unless there is a means of handling this through planning (with stakeholders whose code is used in zope). The similarity of P3K to Y2K gives me some doubt that the branding 'Python 3000' will be seen as the best. I likely won't be the last to draw this similarity and the potential for P3K to put major python projects like zope in turmoil for years.


Martijn Faassen wrote:
Stephan Richter wrote:
On Saturday 01 September 2007 15:33, Martijn Faassen wrote:
I think Zope will be on Python 2.x for many years to come.

I really hope not. A friend of mine and I want to get a bit involved in Python 3000 once it is stable enough that the standard libs can get some attention. At this point I really want to have an initial look at porting Zope 3 packages to Python 3. I really hope we can move to Python 3 in a reasonable amount of time.

Zope 2 is using Zope 3. This means we have some choices:

* upgrade Zope 3 to Python 3 and upgrade Zope 2 to Python 3 too. I suspect especially the latter will be very difficult. Let's go port Plone!

* upgrade Zope 3 to Python 3 and leave Zope 2 behind on an older version of Zope 3. We better come up with a damn good explanation to the community on this one.

* upgrade Zope 3 to Python 3, maintain a Python 2 version too in parallel for Zope 2 to use. A maintenance nightmare in my opinion.

* fork Zope 3. You'll have one version which runs on Python 3, and another version which runs on Python 2. People pick their sides and Zope starts diverging. A terrible mess we should avoid at all costs in my opinion.

Note that without Zope 2, you'll still have to worry about other things that depend on Zope 3, and things that Zope 3 depends on. A lot of people will need to coordinate quite intensively.

Anyway, ignoring Zope 2 and any dependencies, I suspect the porting of Zope 3 to Python 3 will be hard enough by itself to take a long time. Here is where I hope to be pleasantly surprised by better than expected tools.

You mention moving to Python 3 in a "reasonable amount of time". You don't mention what you consider reasonable. I consider it unreasonable to expect a transition within the next 2 years. I also consider 2 years a very optimistic timeframe by the way, as that will be only 1 year after the release of Python 3 and there will be a lot of dust to settle first.

At the very least, we should all agree we will port to Python 2.6 *first*. This is the version of Python that is supposed to work with the 2to3 conversion script. This is the version of Python that will, hopefully, already introduce the bytes type (the using of which should help the conversion script tremendously) and other bits of Python 3.

I'm afraid you and your friend are either asking for a lot of work and trouble, or will have to wait for a long time until Zope will start making use of any changes you make to the Python standard library. I consider other concerns to be far more important to the Zope project than you and your friend wanting to work on the Python standard library before Python 3 is released...



P.S. It's ironic that now that we finally have some measure of clarity and unity in the Zope world concerning evolution of Zope 2 and Zope 3, Python comes along and starts tearing it apart.

Zope3-dev mailing list

Zope3-dev mailing list

Reply via email to