This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author erlendaasland
Recipients erlendaasland, lemburg
Date 2022-01-08.20:56:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Marc-André: since Python 3.6, the sqlite3.Cursor.lastrowid attribute does no longer comply with the recommendations of PEP 249:

Previously, lastrowid was set to None for operations other than INSERT or REPLACE. This changed with ab994ed8b97e1b0dac151ec827c857f5e7277565 (in Python 3.6), so that lastrowid is _unchanged_ for operations other than INSERT or REPLACE, and it is set to 0 after the first valid SQL (that is not INSERT/REPLACE) is executed on the cursor.

Now, PEP 249 only _recommends_ that lastrowid is set to None for operations that do not modify a row, so it's probably not a big deal. No-one has ever mentioned this change in behaviour; there have been no bug reports.

FTR, here is the relevant quote from PEP 249:

    If the operation does not set a rowid or if the database does not support
    rowids, this attribute should be set to None.

(I interpret "should" as understood by RFC 2119.)

So, my follow-up question becomes:
I see no point in reverting to pre Python 3.6 behaviour. I would rather change the default value to be 0 (to get rid of the dirty flag in GH-30380), and to make the behaviour more consistent with how the actual SQLite API behaves.

Do you have an opinion about such a change (in behaviour)?
Date User Action Args
2022-01-08 20:56:53erlendaaslandsetrecipients: + erlendaasland, lemburg
2022-01-08 20:56:53erlendaaslandsetmessageid: <>
2022-01-08 20:56:53erlendaaslandlinkissue46249 messages
2022-01-08 20:56:53erlendaaslandcreate