[DB-SIG] Some obscurity with paramstyle

M.-A. Lemburg mal at egenix.com
Mon Jul 18 14:54:31 CEST 2011

Christoph Zwerschke wrote:
> Am 18.07.2011 13:20 schrieb M.-A. Lemburg:
>> 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.
> Sorry, I was unclear. I meant *if* my driver advertizes itself with
> paramstyle='format', does it need to support '%f' or does it suffice to
> support '%s'? Same for 'pyformat'? From your answer above, it would need
> to support '%f' as well. And does it also need to support flags, width,
> precision, length modifiers such as '%.2f'?
> My concrete problem was that I wanted to support Infinity and NaN where
> Postgres has a different spelling from Python and needs quotes. This is
> more difficult to implement if '%f' is allowed.

The paramstyle only advertises the supported formatting style.

With "format" the supported formatting variants are module
dependent, so it's up to you what to support.

>> 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.
> But as Michael already pointed out, at least the unicode related issues
> are not so obvious. That was also the reason why WSGI needed a new PEP.

True, the DB-API should provide some guidance here as well.
Note that the DB-API spec will have to be valid for Python 2
and 3, so special care has to be taken.

There are two things to consider:

1. parameters
2. data input and output

For parameters, I think the best way to handle this is by allowing
both bytes and Unicode for parameters. Perhaps we can add a
module global which then signals the supported variants.

For data input/output, the situation is difficult, since not
all backends support Unicode, some only configuration dependent
character sets and some others are basically ASCII/binary data

We will likely have to introduce a new TEXT() constructor
which maps data objects to text data and then takes care
of the database specific encoding issues.

There are similar issues with float/decimal and date/time

It would be great if we could resolve all of these using
a data type mapping facility that defines input and output
mappings in an efficient and flexible way.

Marc-Andre Lemburg

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

More information about the DB-SIG mailing list