[DB-SIG] PEP249 - Proposed change to DB-API 2.0

[Chris Cogdon]

On Fri, 27 Apr 2001, M.-A. Lemburg wrote:

> That's easy for you to say ;-) However, your small benefit will cost a
> lot of module writers a lot of work and sometimes it may even
> not be possible getting this right.
>
> To support all the different styles, the module writer would have
> to parse the SQL statement to figure out how to map the paramstyle
> used in there to the native one. Writing an SQL parser is not
> necessarily possible though, since there are so many different
> SQL variations in use out there. I'm not even talking about quoting
> rules here ;-)
>
> If you really care about being able to change database interfaces,
> then you'll have to write an abstraction for your interface anyway,
> so why put the burden on the DB API writer here ? (This only makes
> it harder for interface writers to come up with code which can
> be considered DB API compatible.)

Okay... that could be a fair statement... lets analyse it:

The difference between format and pyformat is really python specific. I
dont know of any C DB-API's that accept python style formatting... in at
least that case, and many other DBs where 'format' is used, python is used
to turn the query and all the arguments into a single string, escaping
each of the argument types appropriately.

Just looking at format and pyformat, I'd hate to have to write a wrapper
function just because some Python API writer chose pyformat rather than
format.... I /like/ the ability to specify my arguments positionally,
rather than having to wrap them up in a dictionary.

A wrapper in this case is very difficult, too, since I'd have to parse the
query for the %s's, then turn them into %(somevarN). Not trivial. It would
be a /lot/ easier for the API writer to have two pieces of code that turn
a format, and a pyformat, request into the appropriate chunks to pass to
the C API.

Of course, this is making a lot of assumptions about what the C API looks
like. In both Mysql, and Postgresql's case, the API takes a single string.
So... what's stopping Python API's for those two Databases from supporting
/all/ the paramstyles?, since they all have to be interpreted one way or
the other.

I can certainly see wanting to place a restriction on the paramstyle
supported if the C API actually supported one or the other of the given
types. But for the above two databases, there's no excuse. The python DB
team could very well supply a library to assist API writers in this
regard.


   ("`-/")_.-'"``-._        Chris Cogdon <chris@cogdon.org>
    . . `; -._    )-;-,_`)
   (v_,)'  _  )`-.\  ``-'
  _.- _..-_/ / ((.'
((,.-'   ((,/   fL