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