[DB-SIG] Some obscurity with paramstyle
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:
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.
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