aaugustin added the comment:
* Thesis *
I belive that using the connection as a context manager is an inadequate API
for controlling transactions because it's very likely to result in subtly
broken code.
As a consequence, my recommendation would be to deprecate this API.
* Argumentation
aaugustin added the comment:
On the other hand there is absolutely nothing broken on the implicit BEGIN
(which is required by dbapi2 specification) nor on the isolation_level
property which controls it. Those shouldn't be touched; there is no reason to.
Nothing broken... unless one
aaugustin added the comment:
Hey -- maintainer of Django's transaction support here.
This ticket was brought to my attention again today. As I know a few things
about this issue and I see Python core devs asking for input, I'll give my
$0.02.
The core of this issue is that, **by default
aaugustin added the comment:
That patch solves the problem, at the cost of introducing an unwieldy API,
operation_needs_transaction_callback.
I'm very skeptical of the other API, in_transaction. Other database backends
usually provide an autocommit attribute.
autocommit is the opposite
aaugustin aymeric.augus...@polyconseil.fr added the comment:
I noticed an inconsistency in the docs, and I think it falls in the Language
Reference section of this ticket. In the definition of the import statement,
after:
| from module import *
we should add:
| from
New submission from aaugustin aymeric.augus...@polyconseil.fr:
The docs for the threading module state that:
The release() method should only be called in the locked state; it changes
the state to unlocked and returns immediately. If an attempt is made to
release an unlocked lock
aaugustin aymeric.augus...@polyconseil.fr added the comment:
I agree with your solution. Unfortunately, I do not know how you would redefine
ThreadError to extend RuntimeError in a C extension.
_thread.error is created line 741 in trunk/Modules/threadmodule.c:
ThreadError = PyErr_NewException
