By George, Michael, you are correct!
I've spent about half of the night reading stuff from all over the Internet,
and the two
methods you suggest are the ones that make sense. I am sold. +1 on requiring
support of
'qmark' and 'named' parameter styles. Implementors, like me, who are running
qmark only
databases will have to parse the dictionary for 'named' parameters and build a
qmark string
as part of the cursor.execute() method. No big deal.
Next question: can't I determine the paramstyle by looking at the second
parameter of c.execute()?
If there is no second parameter, there is no substitution.
If the second parameter is a mapping, the programmer is using 'named'
parameters.
If the second parameter is a sequence (or singleton), the programmer is using
'qmark'.
Only if I support other (nonstandard) styles will I really ever need to have
someone specify
which to expect. Paramstyle is documented as being a read-only attribute in DB
API 2.0.
I am thinking that it may be better to use a different construct in 3.0,
perhaps something like:
connection.setParamstyle('someString') with 'auto' being the default.
---
Vernon Cole
----- Original Message ----
From: Michael Bayer <[EMAIL PROTECTED]>
To: Vern Cole <[EMAIL PROTECTED]>
Cc: db-sig@python.org
Sent: Wednesday, May 30, 2007 8:53:04 PM
Subject: Re: [DB-SIG] paramstyles, again
On May 30, 2007, at 11:17 AM, Vern Cole wrote:
>
> c.execute("SELECT (CASE WHEN infos.pk <", p1,
> "THEN", p2,
> "WHEN (infos.pk >=", p3,
> " AND infos.pk <", p4,
> ")THEN", p5,
> "END) AS x, infos.pk, infos.info FROM infos")
> ###^^^
>
> I think that most people would find the function parameter notation
> much easier to read, write, and maintain than the qmark version.
> There is no question what parameter goes where, no counting, no
> wondering how python or your reader will interpret it. And it will
> look like the built-in python 3 print() function. ;-)
>
seriously ? how would it differentiate a string value that is part
of the generated SQL vs. a string value that is intended to be a bind
parameter ? how do i execute the same SQL string with 100 different
sets of bind parameters, i have to keep building brand new arrays
which contain an arbitrary amalgam of SQL and bind values ? how do
I pass along bind parameters along with a SQL string that was
generated, and i dont know the order of how the parameters fit in ?
how do I do an executemany() ? this idea seems to extract only the
worst inconvenience of positional parameters (i.e., that the order of
params must be known at all times) with none of its advantages (i.e.,
that you dont have to come up with any names), and kills off any
chance of isolating the syntax of a SQL string from its parameterized
values.
as far as guido's quote, I havent checked but I would be pretty
surprised if py3K is doing away with parameterized strings, i.e. "foo
%s" % ('hi') and "foo %(name);" % {'name':'hi'}, so right there is
some variety in how to put together "literals and values".
my vote for paramstyles would be, everyone supports qmark and named,
and we're done. the rest of the styles are all redundant.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
