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
