On Mon, 20 May 2013 12:40:04 -0400, Michael Bayer
<mike...@zzzcomputing.com> wrote:
On May 20, 2013, at 11:20 AM, Carl Karsten <c...@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
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
