[DB-SIG] Some obscurity with paramstyle

[M.-A. Lemburg]

Christoph Zwerschke wrote:
> Am 18.07.2011 09:33 schrieb M.-A. Lemburg:
>> Not really. The DB-API 2.0 allows for a certain number of binding
>> parameter formats, but you shouldn't really invent more.
> 
> My main problem was that the specs do not even properly explain what
> these formats are. E.g. they say 'format' means ANSI C printf format
> codes, and ANSI C means more than just '%s'.

True. Some modules are also using %i and %f to bind
integers and floats.

> So when writing a driver,
> do I need to support '%f' or not?

The question is not whether you need to support them. You can
choose among the available formats. You don't need to support
all of them. One will do just fine.

However, it's good practice to look around a bit at what other
modules are using.

> A new version of the PEP should be
> more specific here. I agree wth you it makes sense to reduce the number
> of formats instead of adding more.
> 
> Am 18.07.2011 09:52 schrieb M.-A. Lemburg:
>> I'm not opposed to a DB API 3, but since there are only a few
>> things on the table for DB API 3 and the adoption of Python 3.x
>> has just started, so it's not all that urgent.
> 
> But you can also see it the other way round. Adoption of Python 3.x is
> so slow because important standards like DB-API or WSGI have not been
> rewritten early enough so nobody knows how to properly implement these.
> Therefore if we want to promote Py 3 it is urgent to do something.

There are not a lot of Python 3 changes necessary and most of
the ones that are (like the exception base class StandardError
which then reads Exception) are obvious fixes.

>> Note that we have added quite a few (optional) extensions to the
>> DB API 2 in recent years, so even though the version number and
>> the base set of required features hasn't changed, there are many
>> feature already addresses in the DB API.
> 
> But if these are optional, you have the same problem as with the many
> parameter formats. People must catch the warning saying the extension is
> not supported and must write code for both case. At least some of the
> extensions like iterator support should become mandatory in the next
> version of the specs.

That will be up for discussion, yes.

We will likely make extensions that are easy to implement for
a lot of database backends, mandatory in DB API 3.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 18 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/