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.
Regards
David
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...
Regards,
Martijn
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@zope.org
Unsub:
http://mail.zope.org/mailman/options/zope3-dev/fairwinds%40eastlink.ca
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
