[Zope-dev] Zope 2.12 features

[Hanno Schlichting]

Philipp von Weitershausen wrote:
> IMHO we shouldn't worry about 2.10 and 2.11 and just care about 2.12 at 
> this point. By now it should work with Python 2.5, right? Let's release 
> it soonish. Not only will it bring Python 2.5 compatibility but it also 
> gets rid of Acquisition-wrapped views and introduces (optional) 
> __parent__ pointers. Three years after having started the 
> implementation, I think it's time to get it out there :)

When it comes to finding a good roadmap for a Zope 2.12 release, let me
state a couple of my ideas, which I'd like to see in that release. Some
of them are done, some of them should be done fairly soon and some might
not make it.

Still I'd put my list out here. Maybe there are others who have been
thinking into the same direction. Here's a list of things I'd like to
see in a 2.12 release:

- Official Python 2.5 and 2.6 support (almost done, requires a community
decision on when we call RestricedPython supported and reviewed)

- Drop Python 2.4 support (so we can start relying on for example
context managers and better generator support amongst others)

- Finish the Zope2 as an egg work (almost done, but needs some final
polishing)

- Reduce the Zope3 dependencies of Zope2 to the actual required set
(I'll work on this in the next weeks, together with Zope2-eggification)

- Acquisition is aware of __parent__ pointers (done)

- Make it possible to use the Zope3 meta ZCML handlers instead of the
ones in Five

This one needs a bit of explanation:

It should be possible and supported to write a different site.zcml and
load the Zope3 meta handlers. As these do have a different semantic in
various places, there's no clear migration path from the Five meta.zcml
handlers. But in order to get rid of the different base classes inserted
by ZCML in the long term, we need to make it possible to use the Zope 3
versions at some point. This doesn't block a Zope 2.12 release, but
would be a real good addition to the Acquistion versus __parent__ work
and another step in the direction of getting rid of Five.

- Let OFS.ObjectManager implement IContainer for real

Since the inclusion of Five into Zope2 ObjectManager claims to implement
 the IContainer interface, but it actually doesn't. Since about Plone
2.1 Plone does monkey patch ObjectManager for that reason and adds the
missing methods to it.

I'd like to get rid of the monkey patch in Plone and let
container.keys(), container.values(), ... become an official API in
addition to container.objectIds() container.objectValues(), ...

This is not trivial on the Zope level, we'd need to take care of items
in all containers by the name of those new methods, but I believe a
solution to that can be found. While this doesn't sound like a major
problem, I think it does lower the learning curve. Telling people
containers in Zope2 or essentially dictionaries is a lot easier then
learning a complete new API. It should also make it easier to share code
between implementations for Zope2 and Zope3. I know of code in Plone and
add-ons that actually rely on these methods to be in place for many
years now.

- Reconsider getting rid of ZClasses

I know this one is not popular, but from what I can see, the number of
supporters of ZClasses are in a minority and the community at large has
moved on into a different direction. Removed ZClasses would allow us to
get rid of much weird code that is only written to support them, in both
product initialization and things like the persistent product registry.

Hanno