Python DB API - commit() v. execute("commit transaction")?

[Jon Ribbens]

On 2017-05-30, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On Tue, 30 May 2017 15:12:55 -0000 (UTC), Jon Ribbens
><jon+usenet at unequivocal.eu> declaimed the following:
>>I can't make head nor tail of what they are trying to say there.
>>Mind you, it doesn't help that the DB-API concept of cursors seems
>>to bear almost no resemblance to the SQL concept of cursors.
>
> 	The main concept is that (set autocommit  to False, for those DB
> adapters that have autocommit) a transaction is implicitly begun on the
> first SQL statement that accesses the data (though I think I've read that
> SQLite doesn't start a transaction until one submits an SQL statement that
> modifies data). 
>
> 	And this behavior apparently matches version 1 of the SQL "standard".
> Version 2 added explicit "begin" -- I suspect Python DB-API adapters to a
> ver2 database are suppose to issue the "begin" whenever the adapter
> believes there is no open transaction.

Indeed. As I say, I think perhaps the source of the confusion is that
DB-API cursors make no sense at all, rather than the problem being
transactions per se.

It's almost as if DB-API was written by someone who had never seen
a database. 'execute' being a method of the cursor rather than the
connection is a logical impossibility - cursors are something that
are returned by SQL execution, not the other way around.

If DB-API had Connection.execute, then Connection.commit wouldn't
be strange. Cursor.execute is bizarre, and it being paired with
Connection.commit is just icing on the bizarre cake.