>>> import sqlite3
>>> sqlite3.paramstyle
'qmark'

The documentation claims that sqlite3 accepts 'named' paramstyle, and :PEP:`249` says in footnote 2:

        Module implementors should prefer 'numeric', 'named' or
        'pyformat' over the other formats because these offer more
        clarity and flexibility.

I think the module should report 'named', as it is preferred, and leave to the documentation the fact that 'qmark' is also supported.

Thanks for bringing this up.

By changing this we would maybe be a little bit closer to PEP 0249. I don't get why the PEP author thinks that 'qmark' is less clear than 'numeric', though. I think they're equally clear.

The real reason why I object changing anything here, however, is that by changing the paramstyle we would break backwards compatibility. Third-party software like ORMs might depend on sqlite3 having paramstyle 'qmark'.

So now someone might suggest to make paramstyle an instance of a subclass of string that will successfully compare against both 'qmark' and 'named'. To which possible suggestion I say forget it. You cannot anticipate how people will really access the paramstyle. And if it would make a difference in real-world scenarios.

I don't think they are equally clear, at least from the point of view of the code written towards the API. I think that

execute("UPDATE authors set name = ?, email = ?, comment = ? WHERE id = ?", (form.name, form.email, form.text, form.id))

is way less clear, more verbose, and prone to alignment errors, than

execute("UPDATE authors set name = :name, email = :email, comment = :text WHERE id = :id", form)

I think this is the reason why the PEP writer prefer named style and. I was about to recode an example using a dictionary for cleaner code, when I noticed the bug. Now I need to hardcode that sqlite3 supports 'named' style, even if paramstyle says other thing, or to dynamically test, in case they decide to remove support for the next release. Both are ugly alternatives.

I said qmark vs numeric. I. e. vs:

execute("UPDATE authors set name = :1, email = :2, comment = :3 WHERE id = :4", (form.name, form.email, form.text, form.id))

The sqlite3 module will always support both paramstyles qmark and named, simply because that is what the underlying SQLite engine supports. What paramstyle says is mostly important for third-party software that works across multiple DB-API compliant database modules. paramstyle enables them to use database supported parameter binding.

In reality, though, there will hardly be a wrapper for DB-API modules that does *not* need to special-case anything depending on the underlying database. So they will hardly ever rely only on the paramstyle and threadsafety parameters.

There is too little value changing the paramstyle attribute. I think the documentation clearly states that both parameter binding methods are supported.