Repository navigation
sqlit3.paramstyle reported as 'qmark' #52443
Description
| BPO | 8196 |
|---|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2010-08-05.14:19:29.300>
created_at = <Date 2010-03-22.00:05:27.952>
labels = ['extension-modules']
title = "sqlit3.paramstyle reported as 'qmark'"
updated_at = <Date 2010-08-05.14:19:29.299>
user = 'https://bugs.python.org/sgala'bugs.python.org fields:
activity = <Date 2010-08-05.14:19:29.299>
actor = 'ghaering'
assignee = 'ghaering'
closed = True
closed_date = <Date 2010-08-05.14:19:29.300>
closer = 'ghaering'
components = ['Extension Modules']
creation = <Date 2010-03-22.00:05:27.952>
creator = 'sgala'
dependencies = []
files = []
hgrepos = []
issue_num = 8196
keywords = []
message_count = 5.0
messages = ['101470', '101551', '101558', '101561', '112982']
nosy_count = 2.0
nosy_names = ['ghaering', 'sgala']
pr_nums = []
priority = 'low'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue8196'
versions = ['Python 2.6']
Activity
sgala commentedon Mar 22, 2010
>>> import sqlite3 >>> sqlite3.paramstyle 'qmark'The documentation claims that sqlite3 accepts 'named' paramstyle, and :PEP:`249` says in footnote 2:
I think the module should report 'named', as it is preferred, and leave to the documentation the fact that 'qmark' is also supported.
ghaering commentedon Mar 22, 2010
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.
sgala commentedon Mar 23, 2010
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
is way less clear, more verbose, and prone to alignment errors, than
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.
ghaering commentedon Mar 23, 2010
I said qmark vs numeric. I. e. vs:
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.
ghaering commentedon Aug 5, 2010
There is too little value changing the paramstyle attribute. I think the documentation clearly states that both parameter binding methods are supported.