Hi Andreas. Yes, this is where my thoughts were going with this in the short and medium term. If you extrapolate this to not only zope, but to other folks that depend upon zope's code base, and to the code zope depends upon, this is not a good scenario. I am thinking about twisted, lxml, and many other code bases and packages. Each project will make a decision of what to do and when - and I think ultimately you will get into a situation of supporting both 2.X and 3.X users at the same time. The timing of when one project moves forward will most likely not be coordinated with other projects.

The ability to use help like the GSoC for making such transitions may also be held back if there code in other repositories that is not yet ready. One thing though is certain and encouraging. There is definitely an advantage with zope's packages and eggs. I'd have to say Jim's foresight and zope's packaging story will have prepared it well for the future. I can not imagine what this could look like if the code was where it was a year or two ago. Despite this, zope is not an island.

But what of the projects that only have in the short term the capability to go one way or the other due to limited resources. For large projects and frameworks, it may be possible to maintain a 2.x and a 3.x. Regardless, it will ultimately require more human resources and splitting mind share between two sets of consumers. Ultimately, the folks that will even want to maintain a 2.x code base will quickly erode since the forefront of development is never the past. Perhaps it will all move more quickly for this reason when python 3K is out for real.


Andreas Jung wrote:

--On 1. September 2007 16:33:58 +0530 Baiju M <[EMAIL PROTECTED]> wrote:

Andreas Jung wrote:
 --On 1. September 2007 16:00:19 +0530 Baiju M <[EMAIL PROTECTED]>
> May be we can try Python 3.0 porting in next GSoC ? :)

 -1 on that. I am pretty sure that this will lead to two different
 codebases which are hard to maintain over long period of time. We
 should stick with Python 2.X for the time being. Otherwise we risk
 compatibility issues with the current deployed Zope installations. We
 must not jump on every train just because it  stop in front of out

I hope your "-1" is for porting to Python 3.0 in next year itself.
May be we should consider it after Python 3.0 final release ?
Otherwise how long will be the "time being" ?

If packages like ZODB, zope.interface & zope.component is
not ported that will be great loss for Python 3.0 programmers.

I am basically speaking here for the Zope 2 world. If we move core components to Python 3000 we have to move the complete Zope 2 core to Python 3000 which will cause a huge disaster because of almost every third party component is likely to break. This is a big risk for the reputation of Zope. I currently don't see how a smooth transition would look like. At the end will have Zope 2 for Python 2.X, Zope 2 for Python 3.X and Zope 3-ish components for Python 2.X and different components for Python 3.X...appears as a nightmare to me.



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to