On Fri, May 17, 2013 at 5:57 PM, M.-A. Lemburg wrote:
>
>> Reading back the upstream thread I also see proposal to leave support
>> for all the current placeholders but mandate drivers to implement
>> qmark and named too. I think this is only going to complicate the
>> implementation of the driver
On Fri, May 17, 2013 at 5:22 PM, Michael Bayer wrote:
>
> The major issue with format/pyformat is that too many DBAPIs take the easy
> way out and just run their string through Python's "%" operator. This
> causes DBAPIs that use the format styles to behave differently from those
> that don't
On 17.05.2013 19:52, Vernon D. Cole wrote:
> I am worried about what the module-level attribute does to thread-safety.
We should clearly document the fact that the module level
attribute serves as default value for new connections - it
should really only be set right after importing the module
or
On Fri, May 17, 2013 at 6:30 PM, M.-A. Lemburg wrote:
>
> We have two extreme positions:
>
> 1. only allow qmark and named, let the driver figure out which one
>is used
>
> 2. only allow format/pyformat
Just FYI, my position is not to only allow format/pyformat: as you
said that would be too
I am worried about what the module-level attribute does to thread-safety.
If this feature is kept, it should be a class attribute, not a module
attribute. We should be doing connections using new style classes.
conn = dbapi_module.Connection()
conn.paramstyle = 'oddball'
conn.connect(your, parame
On 17.05.2013 19:44, Michael Bayer wrote:
>
> On May 17, 2013, at 1:30 PM, M.-A. Lemburg wrote:
>
>> As for how to adjust the paramstyle, I think Vernon's summary
>> is a good one. SQLAlchemy and other applications could then
>> do (*):
>>
>> import dbapi_module
>> # We want named paramstyle on
On May 17, 2013, at 1:30 PM, M.-A. Lemburg wrote:
> As for how to adjust the paramstyle, I think Vernon's summary
> is a good one. SQLAlchemy and other applications could then
> do (*):
>
> import dbapi_module
> # We want named paramstyle on all connections:
> dbapi_module.paramstyle = 'named'
On Fri, May 17, 2013 at 6:00 PM, M.-A. Lemburg wrote:
> > IMHO it is explicit, whether you say:
> >
> > cursor.execute(stmt, { < dictionary>} )
> >
> > vs.
> >
> > cursor.execute(stmt, [ ] )
> >
> > the type of parameters passed indicates the style of params to search
> for. It's explicit via t
Ok, I think we've heard all sides.
We have two extreme positions:
1. only allow qmark and named, let the driver figure out which one
is used
2. only allow format/pyformat
and the original idea of having an adjustable paramstyle,
with the only requirement that modules must provide the
two agr
Am 17.05.2013 18:41, schrieb Daniele Varrazzo:
> You have tested it wrong, and haven't bothered reading the first few
> lines of the first page of the documentation of the driver library.
Yes, sorry for creating confusion today, I tested it wrong and psycopg2
*does* add the quotes.
But then I
On 17.05.2013 18:07, Michael Bayer wrote:
>
> On May 17, 2013, at 11:36 AM, M.-A. Lemburg wrote:
>
>> On 17.05.2013 17:10, Christoph Zwerschke wrote:
>>> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
What other options should be considered?
>>>
>>> Another option would be to get rid of the p
On May 17, 2013, at 12:46 PM, "Vernon D. Cole" wrote:
> One of the things I like about Python is that I do not have to declare my
> data types in advance, as long as I use them correctly. I _like_ the idea of
> not having to pre-set my parameter style. (Having a mix of styles in one SQL
> st
On 17.05.2013 17:50, Daniele Varrazzo wrote:
> Sorry, originally sent this message only to M.-A.L.
>
> On Fri, May 17, 2013 at 11:42 AM, M.-A. Lemburg wrote:
>> psychopg2 uses the 'format' paramstyle and while I agree that
>> it has issues, I think the existing code base using
>> it is large en
On Fri, May 17, 2013 at 5:39 PM, Michael Bayer wrote:
>
> On May 17, 2013, at 11:50 AM, Daniele Varrazzo
> wrote:
>
>>
>> If that's too provocative I think the Python dbapi should mandate the
>> %s and %(name)s formats because they are the only ones to have well
>> defined syntax and escaping ru
On Fri, May 17, 2013 at 5:33 PM, Christoph Zwerschke wrote:
> Am 17.05.2013 18:21, schrieb Daniele Varrazzo:
>
>> Quite the contrary: the quotes should never appear in the query and
>> these examples are correct but...
>
> Just tested this with psycopg2. If you use the clause "WHERE name=%s" and
>
One of the things I like about Python is that I do not have to declare my
data types in advance, as long as I use them correctly. I _like_ the idea
of not having to pre-set my parameter style. (Having a mix of styles in one
SQL statement is just wrong and need not be considered.)
Having said that
On May 17, 2013, at 12:36 PM, Daniele Varrazzo
wrote:
> What you said before doesn't seem the same:
>
> On Fri, May 17, 2013 at 2:59 PM, Michael Bayer
> wrote:
>
>> there's no reason a DBAPI can't keep a particular paramstyle, we just want
>> to make it so that *all* DBAPIs definitely supp
On May 17, 2013, at 12:33 PM, Christoph Zwerschke wrote:
> Am 17.05.2013 18:21, schrieb Daniele Varrazzo:
> > Quite the contrary: the quotes should never appear in the query and
> > these examples are correct but...
>
> Just tested this with psycopg2. If you use the clause "WHERE name=%s" and
On May 17, 2013, at 11:50 AM, Daniele Varrazzo
wrote:
>
> If that's too provocative I think the Python dbapi should mandate the
> %s and %(name)s formats because they are the only ones to have well
> defined syntax and escaping rule and are well known to every python
> developer.
I forgot als
On Fri, May 17, 2013 at 5:23 PM, Michael Bayer wrote:
>
> the proposal includes that only qmark and named are available. There would
> be no pyformat, format, numeric.
What you said before doesn't seem the same:
On Fri, May 17, 2013 at 2:59 PM, Michael Bayer wrote:
> there's no reason a DBAP
Am 17.05.2013 18:21, schrieb Daniele Varrazzo:
> Quite the contrary: the quotes should never appear in the query and
> these examples are correct but...
Just tested this with psycopg2. If you use the clause "WHERE name=%s"
and pass a value without quotes, you get a ProgrammingError from the
dat
On May 17, 2013, at 12:15 PM, Daniele Varrazzo
wrote:
> On Fri, May 17, 2013 at 5:07 PM, Michael Bayer
> wrote:
>>
>>
>>
>> IMHO it is explicit, whether you say:
>>
>> cursor.execute(stmt, { < dictionary>} )
>>
>> vs.
>>
>> cursor.execute(stmt, [ ] )
>>
>> the type of parameters passed
On May 17, 2013, at 11:50 AM, Daniele Varrazzo
wrote:
> Sorry, originally sent this message only to M.-A.L.
>
> On Fri, May 17, 2013 at 11:42 AM, M.-A. Lemburg wrote:
>> psychopg2 uses the 'format' paramstyle and while I agree that
>> it has issues, I think the existing code base using
>> it
On Fri, May 17, 2013 at 5:17 PM, Christoph Zwerschke wrote:
>
> Hm, I forgot DBAPI does not care about SQL; it replaces parameters even
> inside SQL strings. So then, you're right, it can be ambiguous.
>
> By the way, this is really unclear from the DBAPI 2 documentation:
>
> The example in the db
Am 17.05.2013 17:33, schrieb Daniele Varrazzo:> On Fri, May 17, 2013 at
4:10 PM, Christoph Zwerschke wrote:
>>
>> Another option would be to get rid of the parameter completely, and
silently
>> accept both styles, whatever is used in the sql command passed to the
>> execute method.
>
> This is
On Fri, May 17, 2013 at 5:07 PM, Michael Bayer wrote:
>
> On May 17, 2013, at 11:36 AM, M.-A. Lemburg wrote:
>
>> On 17.05.2013 17:10, Christoph Zwerschke wrote:
>>> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
What other options should be considered?
>>>
>>> Another option would be to get r
On May 17, 2013, at 11:36 AM, M.-A. Lemburg wrote:
> On 17.05.2013 17:10, Christoph Zwerschke wrote:
>> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
>>> What other options should be considered?
>>
>> Another option would be to get rid of the parameter completely, and silently
>> accept both st
On 17.05.2013 17:44, Vernon D. Cole wrote:
> On Fri, May 17, 2013 at 4:36 PM, M.-A. Lemburg wrote:
>
>> e.g. passing a
>> dictionary of parameters to a SQL command which uses a mix
>> of qmark and named style parameter markers.
>>
>
> That is a plain, simple syntax error, and will be reported as
Sorry, originally sent this message only to M.-A.L.
On Fri, May 17, 2013 at 11:42 AM, M.-A. Lemburg wrote:
> psychopg2 uses the 'format' paramstyle and while I agree that
> it has issues, I think the existing code base using
> it is large enough that we cannot easily remove that
> paramstyle :-(
On 17.05.2013 17:01, Vernon D. Cole wrote:
> Good point, the others would be optional.
>
> How should the switching be done? My present development head has four
> methods:
>
> 1) adodbapi.apibase.paramstyle = 'named'
> I think this one should be deprecated. Stepping on a module quasi-constant
On Fri, May 17, 2013 at 4:36 PM, M.-A. Lemburg wrote:
> e.g. passing a
> dictionary of parameters to a SQL command which uses a mix
> of qmark and named style parameter markers.
>
That is a plain, simple syntax error, and will be reported as such by the
SQL engine, along with a million other syn
On 17.05.2013 17:10, Christoph Zwerschke wrote:
> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
>> What other options should be considered?
>
> Another option would be to get rid of the parameter completely, and silently
> accept both styles,
> whatever is used in the sql command passed to the exe
If there are only the two styles, you can tell which is expected by looking
at the parameters. If you have a sequence, you use 'qmark', if a mapping,
you use 'named'. Follow the example of string.format() which will accept
either keywords or positional args. Attempting to determine the style by
On Fri, May 17, 2013 at 4:10 PM, Christoph Zwerschke wrote:
>
> Another option would be to get rid of the parameter completely, and silently
> accept both styles, whatever is used in the sql command passed to the
> execute method.
This is impossible:
cur.execute("""Select 'Guess how many params
On May 17, 2013, at 11:10 AM, Christoph Zwerschke wrote:
> Am 17.05.2013 17:01, schrieb Vernon D. Cole:
> > What other options should be considered?
>
> Another option would be to get rid of the parameter completely, and silently
> accept both styles, whatever is used in the sql command passed
On May 17, 2013, at 11:01 AM, Vernon D. Cole wrote:
> Good point, the others would be optional.
>
> How should the switching be done? My present development head has four
> methods:
>
> 1) adodbapi.apibase.paramstyle = 'named'
> I think this one should be deprecated. Stepping on a module q
Am 17.05.2013 17:01, schrieb Vernon D. Cole:
> What other options should be considered?
Another option would be to get rid of the parameter completely, and
silently accept both styles, whatever is used in the sql command passed
to the execute method.
-- Christoph
_
Good point, the others would be optional.
How should the switching be done? My present development head has four
methods:
1) adodbapi.apibase.paramstyle = 'named'
I think this one should be deprecated. Stepping on a module quasi-constant
is never a good idea.
2) adodbapi.connect(connection_str
On 17.05.2013 15:59, Michael Bayer wrote:
>
> On May 17, 2013, at 6:42 AM, M.-A. Lemburg wrote:
>
>> On 17.05.2013 12:09, Vernon D. Cole wrote:
>>> I short time ago I commented to this forum that the 'format' paramstyle was
>>> important to keep, because of widespread use, citing django as an ex
On May 17, 2013, at 6:42 AM, M.-A. Lemburg wrote:
> On 17.05.2013 12:09, Vernon D. Cole wrote:
>> I short time ago I commented to this forum that the 'format' paramstyle was
>> important to keep, because of widespread use, citing django as an example.
>>
>> I have taken the question to the djan
On 17.05.2013 12:09, Vernon D. Cole wrote:
> I short time ago I commented to this forum that the 'format' paramstyle was
> important to keep, because of widespread use, citing django as an example.
>
> I have taken the question to the django developers group and received a
> response that they don
I short time ago I commented to this forum that the 'format' paramstyle was
important to keep, because of widespread use, citing django as an example.
I have taken the question to the django developers group and received a
response that they don't really like the 'format' paramstyle and would be
h
42 matches
Mail list logo
