On 18-07-2011, M.-A. Lemburg wrote:
>> IMHO I would prefer to see the DBAPI have exactly two paramstyles,
>> named and qmark, and have all DBAPIs support both consistently.
>> The (py)format styles continuously introduce the mixing of Python's
>> string formatting behavior with the presentati
On 19/07/11 14:18, M.-A. Lemburg wrote:
> Daniele Varrazzo wrote:
[snip]
> While this is a nice system, it's also very slow. It uses function
> calls and string parsing/conversion for adapting each value. This
> works if you only have to insert/fetch a few rows, but won't be
> feasible for larger v
Chris Clark wrote:
> M.-A. Lemburg wrote:
>> Daniele Varrazzo wrote:
>>
On Jul 19, 2011 3:44 AM, "Federico Di Gregorio"
wrote:
> At least 2 drivers (psycopg and pysqlite) provide a Python->backend
> mechanism based on PEP 246, "Object Adaptation". If other implemento
James Henstridge wrote:
> On Mon, Jul 18, 2011 at 3:52 PM, M.-A. Lemburg wrote:
>> Vernon Cole wrote:
>>> A cursor and/or a
>>> connection should probably be context managers, so that they will work in a
>>> "with" statement.
>>
>> This is was discussed before and it should probably go into
>> the
On Mon, Jul 18, 2011 at 5:28 PM, Federico Di Gregorio
wrote:
> On 18/07/11 11:25, James Henstridge wrote:
>> If all adapters that support transactions function like that, then I
>> think it would be sensible to require them to raise an error in that
>> case. If they don't raise an error, you know
M.-A. Lemburg wrote:
Daniele Varrazzo wrote:
On Jul 19, 2011 3:44 AM, "Federico Di Gregorio"
wrote:
At least 2 drivers (psycopg and pysqlite) provide a Python->backend
mechanism based on PEP 246, "Object Adaptation". If other implementors
are interested I can write a short explanatio
Daniele Varrazzo wrote:
>> On Jul 19, 2011 3:44 AM, "Federico Di Gregorio"
>> wrote:
>>> At least 2 drivers (psycopg and pysqlite) provide a Python->backend
>>> mechanism based on PEP 246, "Object Adaptation". If other implementors
>>> are interested I can write a short explanation about how it wo
> On Jul 19, 2011 3:44 AM, "Federico Di Gregorio"
> wrote:
>> At least 2 drivers (psycopg and pysqlite) provide a Python->backend
>> mechanism based on PEP 246, "Object Adaptation". If other implementors
>> are interested I can write a short explanation about how it works and
>> why it was chosen
Yes, please. I would like to see that. Adodbapi has an output conversion
mechanism, but I don't like it particularly well.
I would be happy to create a fork of adodbapi for a reference
implementation. It will talk to any major database engine, but
unfortunately, only on Windows.
Vernon Cole
(sent
On 18/07/11 14:54, M.-A. Lemburg wrote:
[snip]
> 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
On 18/07/11 11:25, James Henstridge wrote:
> If all adapters that support transactions function like that, then I
> think it would be sensible to require them to raise an error in that
> case. If they don't raise an error, you know that someone somewhere
> is going to write code like the following
Michael Bayer wrote:
>
> On Jul 18, 2011, at 3:52 AM, M.-A. Lemburg wrote:
>
>> Vernon Cole wrote:
>>> On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer
>>> wrote:
Is there a path to changes being made in the DBAPI? i.e. would there be a
DBAPI 3 ?
>>>
>>>
>>> That possibility has been d
On Jul 18, 2011, at 3:52 AM, M.-A. Lemburg wrote:
> Vernon Cole wrote:
>> On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer
>> wrote:
>>> Is there a path to changes being made in the DBAPI? i.e. would there be a
>>> DBAPI 3 ?
>>
>>
>> That possibility has been discussed before, and is particula
On Jul 18, 2011, at 8:54 AM, M.-A. Lemburg wrote:
>
> 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.
OK, but even those DBAPIs can present Pyt
Michael Bayer wrote:
>
> On Jul 18, 2011, at 3:33 AM, M.-A. Lemburg wrote:
>
>>
>> For the next version, we're likely going to reduce the number
>> of allowed formats to just two (%s and ?, IIRC), since having
>> lots of different formats has resulted in much confusion.
>
> Why have both %s and
On Jul 18, 2011, at 3:33 AM, M.-A. Lemburg wrote:
>
> For the next version, we're likely going to reduce the number
> of allowed formats to just two (%s and ?, IIRC), since having
> lots of different formats has resulted in much confusion.
Why have both %s and ? (both positional?) If there is
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
On 18/07/11 14:25, 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
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 do
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
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 pr
James Henstridge wrote:
> On Mon, Jul 18, 2011 at 3:52 PM, M.-A. Lemburg wrote:
>> The case for having cursors automatically closed by
>> is not problematic
>
> I don't think it makes sense to make cursors behave as context
> managers for transaction handling. Transactions are a connection
> lev
On Mon, Jul 18, 2011 at 3:52 PM, M.-A. Lemburg wrote:
> Vernon Cole wrote:
>> A cursor and/or a
>> connection should probably be context managers, so that they will work in a
>> "with" statement.
>
> This is was discussed before and it should probably go into
> the DB API in some form.
>
> I'm no
Vernon Cole wrote:
> On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer
> wrote:
> >Is there a path to changes being made in the DBAPI? i.e. would there be a
>> DBAPI 3 ?
>
>
> That possibility has been discussed before, and is particularly timely given
> that it is impossible to write a PEP 249 c
Michael Bayer wrote:
>
> On Jul 17, 2011, at 1:52 AM, Vernon Cole wrote:
>
>> 2) some major applications (e.g. django) assume %s format.
>>
>> But I am +1 for the idea anyway.
>
> But not all DBAPIs support %s format, do you mean that Django assumes %s
> format for those DBAPIs that are known t
Michael Bayer wrote:
>
> On Jul 16, 2011, at 3:20 PM, Christoph Zwerschke wrote:
>
>> At the PyGreSQL mailing list we're currently wondering whether the 'format'
>> and 'pyformat' paramstyles allow specifying parameters with types other than
>> '%s' - e.g. can I specify my parameter as '%.2f' o
Christoph Zwerschke wrote:
> At the PyGreSQL mailing list we're currently wondering whether the
> 'format' and 'pyformat' paramstyles allow specifying parameters with
> types other than '%s' - e.g. can I specify my parameter as '%.2f' or
> '%(name).2f' if I want to round floats to 2 digits?
>
> PEP
On Jul 17, 2011, at 9:10 PM, Vernon Cole wrote:
>
>
> On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer
> wrote:
>
> On Jul 17, 2011, at 1:52 AM, Vernon Cole wrote:
>
> > 2) some major applications (e.g. django) assume %s format.
> >
> > But I am +1 for the idea anyway.
>
> But not all DBAPIs
On Sun, Jul 17, 2011 at 8:54 AM, Michael Bayer wrote:
>
> On Jul 17, 2011, at 1:52 AM, Vernon Cole wrote:
>
> > 2) some major applications (e.g. django) assume %s format.
> >
> > But I am +1 for the idea anyway.
>
> But not all DBAPIs support %s format, do you mean that Django assumes %s
> format
On Jul 17, 2011, at 1:52 AM, Vernon Cole wrote:
> 2) some major applications (e.g. django) assume %s format.
>
> But I am +1 for the idea anyway.
But not all DBAPIs support %s format, do you mean that Django assumes %s format
for those DBAPIs that are known to do so ? Shouldn't they be at le
On Sat, Jul 16, 2011 at 2:27 PM, Michael Bayer wrote:
>
> On Jul 16, 2011, at 3:20 PM, Christoph Zwerschke wrote:
>
> > At the PyGreSQL mailing list we're currently wondering whether the
> 'format' and 'pyformat' paramstyles allow specifying parameters with types
> other than '%s' - e.g. can I spe
On Sat, Jul 16, 2011 at 3:27 PM, Michael Bayer wrote:
> IMHO I would prefer to see the DBAPI have exactly two paramstyles, named and
> qmark, and have all DBAPIs support both consistently. The (py)format
> styles continuously introduce the mixing of Python's string formatting
> behavior with
On Jul 16, 2011, at 3:20 PM, Christoph Zwerschke wrote:
> At the PyGreSQL mailing list we're currently wondering whether the 'format'
> and 'pyformat' paramstyles allow specifying parameters with types other than
> '%s' - e.g. can I specify my parameter as '%.2f' or '%(name).2f' if I want to
>
At the PyGreSQL mailing list we're currently wondering whether the
'format' and 'pyformat' paramstyles allow specifying parameters with
types other than '%s' - e.g. can I specify my parameter as '%.2f' or
'%(name).2f' if I want to round floats to 2 digits?
PEP 249 has only '%s' in the example,
34 matches
Mail list logo
