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

Martijn Faassen faassen at startifact.com
Tue May 5 09:45:31 EDT 2009

Martin Aspeli wrote:
> Martijn Faassen wrote:
>> Martijn Faassen wrote:
>>> In order to get to a conclusion:
>>> I haven't seen convincing arguments yet *not* to drop the Python 2.4 for 
>>> new releases of the Zope Toolkit libraries.
>>> I'd like to phrase the debate in those terms instead of the reverse, 
>>> because ensuring Python 2.4 compatibility is an additional burden for 
>>> developers and we need good arguments for *not* dropping this burden.
>> Since I haven't seen such arguments besides the Plone 3.x related ones, 
>> I will amend the zope toolkit decisions about this.
> We've had some more discussions about this and the Plone release 
> schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, 
> it will effectively render it inaccessible to Plone users for the next 
> 12-18 months.

As I pointed out, it is effectively inaccessible for Plone users anyway, 
as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 
libraries just like that and expect anything to work.

 > I agree that some of the refactored ZTK
 > components don't make sense if they're bundled with Zope 2.10 in
 > pre-refactored form.

Yup, they won't.

 > However, the idea is surely also to support new
 > and more focused components in the toolkit.

There are no such new and more focused components even on the drawing 
board yet. I highly doubt that the first release of the Zope Toolkit 
will contain such components.

> We're not comfortable moving to Zope 2.12 for the 3.x 
> series. We may be able to move to Zope 2.11, which *may* work with 
> Python 2.5, but this is not clear.
> That makes the potential user base for new-and-dependency-isolated Zope 
> components quite a bit smaller. 

I don't believe in this Plone (for *existing Plone releases*) user base 
anyway, so I don't think it's getting smaller.

If we'd have released a Zope 3.5 that didn't have Python 2.4 support, 
would you have complained that you cannot use Zope 3.5 with an existing 
Plone release?

This is the same as trying to use Zope 3.4 and Zope 3.3 components 
together (though the changes from Zope 3.4 to the Toolkit are *bigger* 
as we move things around). It *might* just work in some cases, but it's 
unlikely it will.

> At the end of the day, it may not make much of a difference. However, I 
> am still puzzled as to why we you are trying to base a decision on 
> arguments *against* breaking compatibility. The main argument *for* 
> dropping compatibility seems to be a hand-wave towards an  added 
> maintenance burden. Is that really so? Are we struggling to release 
> components that work across Python versions?

Sorry, I won't let you turn this back around again. :) Arguments for 
increased maintenance burden will need to be realistic.

I will note that Grok 1.0 won't work with the Zope Toolkit either; we're 
sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit.

> If there are Python 2.5 features we really want to use, then I 
> understand. Otherwise, I think as a general principle it makes sense to 
> always aim for the widest amount of compatibility possible, at least 
> when it comes to the core Zope Toolkit, which, by its very nature, aims 
> to underpin a number of heterogeneous platforms with different 
> constraints. I'd rather hope Plone was considered one of those platforms. ;)

It is, but again, it's just wishful thinking that the toolkit libraries 
as they are released today will work in combination with a existing 
release of Plone.



More information about the Zope-Dev mailing list