[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

[Chris Clark]

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 
http://mail.python.org/pipermail/db-sig/2007-June/005084.html (although 
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
    application".
      * 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
        needed.


Chris