Hi! If there are no objections, I'd like to merge two changes into the Zope-2_8-branch before 2.8.1 is released: 1.) Backports from zope.tal to TAL and a small modification of ustr: http://svn.zope.org/?rev=37613&view=rev http://svn.zope.org/?rev=37614&view=rev This is a fix needed by Five to handle massageIDs correctly. I don't expect any backwards compatibility issues. 2.) Backport of Interfaces.bridge from the Zope trunk: http://svn.zope.org/?rev=33270&view=rev This is a new utility function for z2 -> z3 interface migration. It doesn't change any existing code, so there should be no risk. I guess it would be useful for many products, at least CMF trunk could benefit from that bridging code. Any comments? Cheers, Yuppie
yuppie wrote:
If there are no objections, I'd like to merge two changes into the Zope-2_8-branch before 2.8.1 is released:
1.) Backports from zope.tal to TAL and a small modification of ustr:
http://svn.zope.org/?rev=37613&view=rev http://svn.zope.org/?rev=37614&view=rev
This is a fix needed by Five to handle massageIDs correctly. I don't expect any backwards compatibility issues.
+1
2.) Backport of Interfaces.bridge from the Zope trunk:
http://svn.zope.org/?rev=33270&view=rev
This is a new utility function for z2 -> z3 interface migration. It doesn't change any existing code, so there should be no risk. I guess it would be useful for many products, at least CMF trunk could benefit from that bridging code.
+1 Normally I would be hesitant about adding new features to a minor release; this case is different, though: - the bridge code seems to be completely isolated from anything else, so there's zero risk to jeopardize any existing code. - it will encourage people to write more Zope 3 style interfaces from the beginning. Currently Five's Zope 2 -> Zope 3 bridging code encourages people to write more Zope 2 interfaces, often only to bridge them to Zope 3 ones. That clearly isn't the optimal way: Zope 3 interfaces are not only future-proof and more powerful but Zope 2 interfaces are also rarely needed at all (there are a couple of uses, e.g. in some catalog indexes, which is why we do need Zope 3 -> Zope 2 bridging). Philipp
As developed in a long thread starting at http://mail.zope.org/pipermail/zope/2005-July/160433.html there appears to be a race bug in the Microsoft Windows socket implementation, rarely visible (but disastrously when so) when multiple processes try to create an "asyncore trigger" simultaneously. Unfortunately, the relevant code appears to have originated in Medusa, and then got copy/paste'd all over creation. ZEO's copy is in ZEO/zrpc/trigger.py, and I've fixed it for ZODBs 3.2.10, 3.4.1 and 3.5. Zope-2_7-branch is using a 3.2.10 pre-release now, but no other version of Zope has stitched in a repaired ZODB yet. The original Medusa code appears to be in lib/python/ZServer/medusa/thread/select_trigger.py I've repaired that in CVS Zope-2_7-branch, and am in the process of repairing the same file in SVN Zope trunk and SVN Zope 2.8 branch. SVN Zope trunk and Zope 2.8 branch appear to inherit yet a 3rd copy of this code, in their lib/python/zope/server/trigger.py which appears to come from an older Zope3 snapshot. Zope3 trunk does not appear to contain any Medusa code (at least not under that name), but does contain zope/server/trigger.py which appears more to be a copy of an older version of ZEO's trigger.py than of Medusa's select_trigger.py. The short course here is that I'm repairing all but only the copies of this code that do _not_ appear in anybody's zope/server/trigger.py That file appears to have been introduced in Zope3, and I've lost track of which branches of Zope3 are still active now. I'll open a Zope3 collector issue on this, and will be happy to help repair it, but because I spend most of my Zope time trying to help Zopes 2.7 and 2.8 along, those are the only Zope versions where I'm confident about changing the right stuff in the right places. I'll repair Zope3 trunk's zope/server/trigger.py unless someone can tell me it's no longer used, but someone else will have to port that change to the still-active Zope3 branches (including the one(s) used by Zope 2.8 and Zope trunk).
participants (3)
-
Philipp von Weitershausen -
Tim Peters -
yuppie