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 only. 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 values. 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 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/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
