> The idea was to not take away from what's there already: The sqlite3 module already has a feature to inspect a command and begin or commit automatically. Just stripping that away *removes* a feature that has been available for a long time. I'd rather give the
client more control instead of less and let him fine tune this behaviour.

For the sake of clarity, I haven't proposed to remove anything. I'm focusing on preserving the same behavior by default (with its advantages and drawbacks) and providing more control for users who need a different behavior, for instance people who use SQLite as an application file format or as a web application storage backend.


> When starting with Python I always thought that code like this is harmles:

    >>> conn = sqlite3.connect("test.db")
    >>> data = list(conn.execute("select * from mytable"))

> Currently it is, but only because sqlite3 module parses the select as DQL and does not lock the database.

It will absolutely remain harmless with my proposal, if you don't change your code.

However, for that use case I would like to encourage the use of autocommit mode. That's really the semantics you want here.


In fact, you've written several sentences along the lines "currently we have $ADVANTAGE". It's easy to (mis)interpret that as implying that I'm trying to remove these advantages. But that's simply not true.


To sum up, if I understand correctly, in_transaction gives you the ability to fight the behavior mandated by the DB API in client code, because you understand it well.

My take is to avoid the problem entirely, and not inflict it to new users, by providing an option to start in autocommit mode and then create transactions only when you want them.

The DB API doesn't forbid this option. It just prevents it from being the default (even though it's what the average developer expects).

It solves the problem of using SQLite as an application file format. Use autocommit as long as you're just reading; start a transaction before writing; commit when you're done writing.

Of course, that only applies to new software. Existing software can happily keep using the current behavior, which will be preserved at least for the lifetime of Python 3.