[Zope-dev] dropping Python 2.4 support in the Zope Toolkit?
optilude+lists at gmail.com
Tue May 5 05:55:33 EDT 2009
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. 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. ;)
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Zope-Dev