3 ms·
That looks actually more like a use case for a context manager, i.e. with transactional as transaction: # do something It's pretty clear at the
by matthiasv 11y ago
That looks actually more like a use case for a context manager, i.e.
with transactional as transaction:
# do something
It's pretty clear at the call site what is and what isn't transactional and most importantly is practically the pythonic way of writing code with guaranteed cleanup.
- itp 11y agoWe really wanted to support a context manager there, believe me. IIRC the problem was there is/was no facility for retry with a context manager, so there would still need to be structure around it. I could be wrong, though -- I only remember being seduced by the context manager option a couple times before running into the same wall. I don't think the context manager, even if it had been doable, would have supported composition in the style of: @transactional def thing_one(tr, *args): # stuff @transactional def thing_two(tr, *args): # other stuff @transactional def both_things(tr, *args): thing_one(tr, args) thing_two(tr, args) If it's not clear, in this case a caller could provide a database object to thing_one or thing_two and they would be executed as a single atomic transaction, but a call to both_things with a database object would execute both thing_one and thing_two inside of a single atomic transaction.
- icebraining 11y agoYou're not wrong, it was an explicit decision: https://mail.python.org/pipermail/python-ideas/2013-May/020633.html https://mail.python.org/pipermail/python-ideas/2013-May/0206...