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

[Martin Aspeli]

Martijn Faassen wrote:
> Hey,
> 
> 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. 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 agree that some of the refactored ZTK 
components don't make sense if they're bundled with Zope 2.10 in 
pre-refactored form. However, the idea is surely also to support new and 
more focused components in the toolkit.

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?

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. ;)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book