[DB-SIG] paramstyles, again

[Vern Cole]

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 <mike_mp at zzzcomputing.com>
To: Vern Cole <kf7xm at yahoo.com>
Cc: db-sig at 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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070531/1bb65c67/attachment.htm