[Zope-dev] Zope 2.12 features

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hanno Schlichting wrote:
> 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)

+1 for 2.5;  I'm pretty sure 2.6 is not there yet, and may be too hard
to aim for in one release.

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

- -1.  Sugar is never sweet enough to give up the fallback to "known
good."  We should *not* be adding support for new Python versions and
removing it for older ones in the same release.

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

+1.

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

- -0 for a 2.12 release.  I don't see enough win to make it worth any delay.

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

+0.

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

There is already too much "superstition" around that code: there is no
good reason for filesystem products to put anything in that registry at
all, aside from nostalgia.

OTOH, -1 to doing stuff just to appease the
"Zope2-product-in-a-package-outside-the-Products-namespace" crowd:  they
didn't get the joke, there.  Having stuff masquerading as "reusable
Python" shich is still loaded up with Zope2 dependencies, including the
expectation that it will have its 'initialize()' function called at
startup, is silly.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJCgfI+gerLs4ltQ4RAmgmAKDFO09wecuER19vYLHX3NF+9KYdXgCgidR9
37ulcN2TVF0Sl1aTRBLo3KM=
=6jnQ
-----END PGP SIGNATURE-----