The transaction manager in zope is decoupled and already provides a much more robust and well tested interface.
Only real dependency is the zope.interface package.
I know its fashionable to rewrite things from scratch in python, and to bash on zope, but its just sad sometimes how much stuff people put out that just can't meet any real world applications beyond their initial design constraints or toy apps, because they were never written with flexibility in mind or the needed domain expertise.
the zope developers are solving complex real world problems today, might as well learn something from their expertise.
Sure; this was just an example, and I wasn't proposing it replace anything; that's why it just went in a scratch directory. The code you link to would replace Manager, and provides interfaces for the transactions themselves; except it calls Manager a Transaction, and the objects it contains DataManager. A lot of the additional code it provides seems to be for logging and debugging, and two-phase commit. All good code, I'm sure.
In generally WSGI/middleware applies to the integration of code like that into the request cycle; if the transaction handling code was linked to WSGI that would be a bad sign. It's best that the integration code be short, since the transaction code should also be usable outside of a web request, and if the integration code is long then that's a sign the code being integrated is obtuse or incomplete.# Ian Bicking
wrap the Zope transaction manager into a WSGI application interface as above and the world can take advantage of its great maturity.
I think for 90% of the use cases, Zope's implementation is far too complicated. In typical cases, you're using a DBAPI driver and you have a database connection (perhaps pooled, but this is an orthogonal issue) per request. In the end, if there is an exception, you rollback; otherwise you commit. It isn't that hard. I'd rather not include a huge chunk of code like that in my webserver unless I absolutely need it. Minimilism is a very good thing.