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

[Jon Ribbens]

On 2017-05-31, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Tue, May 30, 2017 at 4:57 PM, Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> A DB-API "cursor" is a database connection
>
> Baloney. Creating a cursor does not spawn a new connection to the
> database. Cursors created from a connection share that connection.

Baloney yourself - I didn't say it was a *new* connection. In DB-API,
a Connection is basically nothing - you can do nothing at all with it.
A Cursor is actually what any other language would call a connection.
If you say that this description is confusing connections and cursors,
then you have understood my point - that's exactly what DB-API is doing.

>> No other language's database API works this way - they all work by
>> executing queries on the connection (I checked Go, Java, PHP, Ruby,
>> Perl).
>
> So Python is unique in this regard. What of it?

So it's a big hint that Python is wrong, if it takes terminology used
by databases and all other languages, and uses that same terminology
to mean something that no other language uses it to mean. Having your
own quirky API for a standard function is generally not a good thing,
especially when the quirky API has no advantages whatsoever.

> But it may be the case that the code doing the commit is only loosely
> coupled to the code that modified something and you don't have that
> cursor hanging around still, in which case the method saves you the
> need to create a *second* cursor in order to issue a "commit"
> statement.

Yes, this is indeed a problem with DB-API - you have to keep *two*
objects around all the time (the connection and the cursor) and pass
them to functions, etc, when in any sensible system as used by all
other languages you would only need to pass the connection.