[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)
Chris.Clark at actian.com
Mon May 20 21:31:25 CEST 2013
On Mon, 20 May 2013 12:40:04 -0400, Michael Bayer
<mike_mp at zzzcomputing.com> wrote:
> On May 20, 2013, at 11:20 AM, Carl Karsten <carl at personnelware.com> wrote:
>> Does anyone on in this discussion actually want named parameters for
>> their own use, or does it seem like something someone might want, so
>> lets try to make that happen just in case?
>> I can see the benefit (easier to read code) but given the amount of
>> problem it would seem to cause, it doesn't seem worth it.
>> But I have lost track of the pros-n-cons of the various options. I
>> think it is time to start a wiki with pointers to example code.
> We should re-locate the original thread where I think a lot more DBAPI authors weighed in, and we had decided on qmark and named after much deliberation.
> I maintain that a paramstyle that specifically does not overlap with Python's own built-in formats is more appropriate, for the reasons I've outlined (works poorly with other systems that already deal with Python formatting, leads DBAPI authors to be lazy, rely too heavily on Python built-in behavior rather than considering bound parameters as a special case, leads to inconsistent implementation schemes, confuses end users since it isn't "true" Python formatting, is not in line with commonly accepted standard conventions in the greater database adapter community).
Apologies for the long mail, I've trimmed it as much as I could in the
time I had.
We had a voting thread, for example
there where earlier threads in 2006 April).
I got the impression supporting (at least) 2 parms styles in a single
was a comprise. From my perspective I'd prefer a single style, qmark.
I think Daniele and are in agreement that supporting two different
styles in a driver is not ideal. I suspect we disagree on what the
single style should be :-)
I'm ok with the other styles being optional, this helps with backwards
compat for old applications (I'm ignoring how to enable that backwards
compat). Gerhard had a suggestion on how to deal with transitioning over
to a single style
http://mail.python.org/pipermail/db-sig/2006-April/004681.html the issue
then was that we didn't have any sample code, it looks like Daniele has
started on that https://github.com/dvarrazzo/qmarkpg
For most drivers (for example, ODBC and JDBC) there is a single bind
parameter indicator and it is '?', the driver implementer MUST implement
it. The original Python dbi spec was (I think) a thin veneer over the
native drivers that did not attempt to hide the DBMS parameter passing
symbols. This appears to be the real sticking point, we have 2 use cases
1. "I want to write a python database application"
Some users want a single way that works with all backends. I'm
conveniently ignoring SQL dialect issues here, for a simple
"SELECT col1 from some_table where col2 = ?" SQL dialects are
not an issue. The ODBC (etc.) spec ignore SQL dialect issues too.
2. "I want to write a python <insert favorite DBMS here> database
* they really want Python access to the database API that doesn't
get in the way. They are not concerned about other vendors.
There is nothing wrong with this approach for those users but
this isn't a good use case when support for other backends is
More information about the DB-SIG