[Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Jens W. Klein]

Am Tue, 05 May 2009 16:22:44 +0200 schrieb Martijn Faassen:
[...]
> I care about the Plone user base, but would you really have said: "okay,
> we should not move to Python 2.5 for Zope 3.5, because people on Plone
> which is still based on Zope 3.3 may want to use bits from Zope 3.5?"

Unfortunately Plone is still based on Zope 2.10. We may have a release 
based on Zope 2.11 at end of year or maybe earlier. But the power of 
extending and using newer version of some libraries is essential.
 
> I don't think you would have.
> 
> I seriously think that people who think they can just drop in Zope
> Toolkit components into an existing Plone release might not see the true
> difficulties involved. If this is the only argument to stay compatible
> with Python 2.4, then it is a bad one.

I feel the difficulties in my every days work. I love to work with ZTK 
i.e for AGX (no web context at all) or our recent preparing works for 
Devilstick (data centric model-runtime) or together with 
repoze.bfg (integration web-app work).

Then back in CMS Plone-business reality strikes back, using Zope 3.4 (or 
3.5dev KGS) or ZTK is introduces headaches. I use the newer techs because 
they simplify a bunch of things. Also I can reuse my packages and dont 
need to reinvent everything everyday.

[...] 
> Anyway, if I'm correct, the argument in favor of Python 2.4 support in
> the Zope Toolkit is as follows:
> 
> * Plone is still on Python 2.4 and Zope 2.10

reality sucks. but stabilty is essential.
 
> * Plone would like to use libraries like z3c.form 2.0 that already are
> on the Zope Toolkit

yes

> * in order to do this, Plone developers will tell users of
> z3c.form-based code on Plone to replace vast amounts of libraries in
> their Plone install with Zope Toolkit libraries.

or zope 3.4 libs as we were used to in past.

> * the Plone developers will make sure that this works so that the Zope
> Toolkit developers don't have to worry about it.

well, Zope3/ZTK code is usally good and tested code. most of the time 
(except something like Five steps in ;) ) it works.

> * the Plone developers are asking not to drop Python 2.4 support in the
> Zope Toolkit now because they want to do such a thing.

+1

> The question now is whether this is realistic from the Plone
> perspective. Have people tried this? Do the z3c.form tests run, and the
> Plone tests? Have people done this with Zope 3.4 libraries (which have
> been released for a while)? Or have things just worked based on luck and
> magic? (since Plone never actually uses a Zope Toolkit container
> implementation it hasn't been an issue that there are two versions in
> the same codebase, say)

z3c.form is one example. Yes we tried this, yes Zope 3.4 libs are working 
in most cases. Yes it was luck, and became magic if Five was involved. 
And no, I dont tried to make it work with ZTK except for some very core 
and low-dependecy packages.
 
> How hypothetical are the scenarios we're talking about here?

Since we have buildout and version pinning we used newer libraries from 
zope 3.4. This is for about 2 years. 
Nothing hypothetical.
Those scenarios are reality.
 
> All too often in the past we've *not* done things because someone
> somewhere has an argument, possibly quite weak and unrealistic, to hold
> up the process. I'm all for listening to people's arguments, but in
> order to make progress we must also be willing to disappoint people

I like how you push ZTK forward. Its great work. But at some point you 
have to give other slower species the chance to move with you. So 
possibly the point is reached to settle down a bit again. Give ZTK the 
chance to be used by a broad community. 

just my 0.02 Eur

Jens
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance