Title: sqlit3.paramstyle reported as 'qmark'
Type: Stage:
Components: Extension Modules Versions: Python 2.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: ghaering Nosy List: ghaering, sgala
Priority: low Keywords:

Created on 2010-03-22 00:05 by sgala, last changed 2010-08-05 14:19 by ghaering. This issue is now closed.

Messages (5)
msg101470 - (view) Author: Santiago Gala (sgala) Date: 2010-03-22 00:05
>>> import sqlite3
>>> sqlite3.paramstyle

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.
msg101551 - (view) Author: Gerhard Häring (ghaering) * (Python committer) Date: 2010-03-22 23:30
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.
msg101558 - (view) Author: Santiago Gala (sgala) Date: 2010-03-23 01:27
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.text,

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.
msg101561 - (view) Author: Gerhard Häring (ghaering) * (Python committer) Date: 2010-03-23 07:00
I said qmark vs numeric. I. e. vs:

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

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.
msg112982 - (view) Author: Gerhard Häring (ghaering) * (Python committer) Date: 2010-08-05 14:19
There is too little value changing the paramstyle attribute. I think the documentation clearly states that both parameter binding methods are supported.
Date User Action Args
2010-08-05 14:19:29ghaeringsetstatus: open -> closed
resolution: rejected
messages: + msg112982
2010-03-23 07:00:31ghaeringsetmessages: + msg101561
2010-03-23 01:28:01sgalasetmessages: + msg101558
2010-03-22 23:30:53ghaeringsetpriority: low

messages: + msg101551
2010-03-22 18:21:53georg.brandlsetassignee: ghaering

nosy: + ghaering
2010-03-22 00:05:27sgalacreate