8000 sqlit3.paramstyle reported as 'qmark' · Issue #52443 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

sqlit3.paramstyle reported as 'qmark' #52443

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sgala mannequin opened this issue Mar 22, 2010 · 5 comments
Closed

sqlit3.paramstyle reported as 'qmark' #52443

sgala mannequin opened this issue Mar 22, 2010 · 5 comments
Labels
extension-modules C modules in the Modules dir

Comments

@sgala
Copy link
Mannequin
sgala mannequin commented Mar 22, 2010
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']
@sgala
Copy link
Mannequin Author
sgala mannequin commented Mar 22, 2010 
>>> 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.

@sgala sgala mannequin added the extension-modules C modules in the Modules dir label Mar 22, 2010
@ghaering
Copy link
Mannequin
ghaering mannequin commented 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 soft 8000 ware 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
Copy link
Mannequin Author
sgala mannequin commented 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

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.

@ghaering
Copy link
Mannequin
ghaering mannequin commented Mar 23, 2010

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.

@ghaering
Copy link
Mannequin
ghaering mannequin commented 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.

@ghaering ghaering mannequin closed this as completed Aug 5, 2010
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@erlend-aasland erlend-aasland mentioned this issue Dec 30, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
extension-modules C modules in the Modules dir
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0 participants
0