Why don't you grep the pysqlite for ifdefs. You'll find that there are a number of differences that are dependant on the sqlite version.

In the case of an old version the original behavior is retained, so I don't understand why raising a runtime error makes sense.

Search SQLITE_VERSION_NUMBER in \Modules\_sqlite\ folder, basically these are these cases:

• use new API for better performance
• synchronize the behavior
• use new feature of SQLite

The first two don't introduce different behaviors. The third one is documented clearly, and if run a code on old SQLite, the program will abort.

While with this patch, please imagine this scene: the same program, under the same version Python, can get different results silently.

If this happened, it's very hard to find where the bug is, the programmer may get insane. Even worse, no one noticed the difference at all, but polluted results may break things (at that time or in the future) like a specter.

Moreover, IMO sqlite3_stmt_readonly() is not suitable for detecting statements, it seems it was designed for telling if a statement will changed the database file.

Similarly, this patch is intended to do away with the necessity to parse comments. This patch fixes the issue you referenced.

With this patch, this statement can't be executed:
conn.execute('/* comment */ vacuum')

is_dml is true, then a transaction is begun implicitly before the executing, but VACUUM can't execute inside a transaction, so the error raised:
sqlite3.OperationalError: cannot VACUUM from within a transaction

You still have to detect leading comments.