In this case, the answer is clear to me. :)
We should fix the offending Z3 code to match the interface.
Similarly, we should fix the uses of get_transaction.
Tim Peters wrote:
I'm merging ZODB 3.4 into Zope on a branch. As Tres noted earlier in a checkin comment, a test failure results, because at the ZODB sprint we fleshed out IDataManager and an older Zope3 class claiming to implement IDataManager no longer does. Since Zope trunk doesn't "own" either the IDataManager definition nor the old Zope3 code, it's unclear how best to proceed:
ERROR: testInterface (zope.app.mail.tests.test_delivery.TestMailDataManager) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Code\Zope\lib\python\zope\app\mail\tests\test_delivery.py", line 46, in testInterface verifyObject(IDataManager, manager) File "C:\Code\Zope\lib\python\zope\interface\verify.py", line 93, in verifyObject return _verify(iface, candidate, tentative, vtype='o') File "C:\Code\Zope\lib\python\zope\interface\verify.py", line 60, in _verify raise BrokenImplementation(iface, n) BrokenImplementation: An object has failed to implement interface <InterfaceClass transaction.interfaces.IDataManager>
The abort_sub attribute was not provided.
An expedient hack would be to castrate ZODB 3.4's IDataManager definition, back to what it was before the ZODB sprint. That's unattractive for obvious reasons (like, e.g., that the old definition lied about what the interface actually is).
Current Zope3 trunk will have the same problem with ZODB 3.4 in its MailDataManager class, so that's "the right place" to fix it. But then the repaired version also needs to be merged into the "old" Zope3 code Zope trunk is trying to use. "The old" zope/app/mail/delivery.py also uses the deprecated get_transaction(). Perhaps current Zope3 trunk's delivery.py could just be slammed into the tag used by (or a new tag created for) Zope trunk?
get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear).
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce