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

Michael Bayer mike_mp at zzzcomputing.com
Mon May 20 18:40:04 CEST 2013

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).

More information about the DB-SIG mailing list