Dear folks,
Vern Cole wrote:
My company's MS Exchange server seems to have eaten my first attempt
to send this, so here is another try. Sorry that it seems a bit stale
in the stream. Here is my suggestion about what to do to paramstyles
-- i.e. kill it off completly.
>> Make qmark, numeric, and named all required. It does not take much
>> Python code to adjust between them (to be able to implement any one
>> in terms of any
>> other) . Then maybe SQL will be modivated to get to numeric. Why
>> let them bring us down to the least common denominator?
>
>-1. It may not have taken much to implement on your backend, but that
may
>not be universally true. Even if "not much" code is required, the
amount is
>greater than zero, for no obvious benefit. Even requiring qmark may
require
>non-trivial code additions to some existing API modules, but I think the
>effort would be justified. Requiring numeric and named as well just
adds a
>gratuitous implementation hurdle, and it would seriously hurt the
>acceptability of this API change.
I was watching an interesting video a few days ago. I highly
recommend it. The video is Guido van Rossum talking about plans for
Python 3000.
http://video.google.com/videoplay?docid=-6459339159268485356
There is a concept that if there is more than one way to do something
in a computer language, one of them is probably wrong.
Agreed. But the real problem is getting people to agree which of them
is right!!
I would suggest that requiring every implementation to support every
kind of parameter passing is a large step in the wrong direction.
I would not necessaily accept that view. In fact, once everybody
supported every form then few
would be tempted to promote their only answer as the one right answer
AND we could let
the users decide which worked best for them.
Python 3 will do away with the special 'print' statement. It will be
replaced by a function 'print()' with an unlimited argument list. I
suggest that, for parameter passing, we use an execute() method with
an unlimited argument list. In other words, we should pass SQL
parameters as python parameters. Let me use some SQL which I am
fighting with right now as an example. This is from the SQLAlchemy
test suite, and I am struggling to make the new version of adodbapi
execute it without throwing up.
###vvv(begin qmark example)vvv
sql = """SELECT (CASE WHEN infos.pk < ? THEN ? WHEN (infos.pk >= ?
AND infos.pk < ?) THEN ? END) AS x, infos.pk, infos.info FROM infos"""
parm=[3, 'lessthan3', 3, 7, 'gt3']
c.execute(sql,parm)
###^^^
I suggest the following:
###vvv(begin python3 example)vvv
p1, p2, p3, p4, p5 = [3, 'lessthan3', 3, 7, 'gt3']
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. ;-)
OK. This is no worse than qmark and almost as good as named,
and if I needed to implement it, I would code it to transform this
new method's arguments into named or numeric parameter format SQL
with a dictionary or list of values and
pass it to the code I already have that handles them.
In fact, I do not see this as any cleaner or clearer than the named
parameter style.
di = {'p1':3, 'p2':'lessthan3', 'p3':3, 'p4':7, 'p5':'gt3' }
c.execute("""select (case when info.pk < :p1
then :p2
when (infos.pk >= :p3
and infos.pk < :p4
) then :p5
end) as x, infos.pk, infos.info from infos""", di)
Furthermore, I agree with the argument that was put forward earlier
that it is very important that the form we employ should look enough
different from string interpolation that users realize that muliple
executions of the same SQL statement with different parameter sets
is just that and not executions of multiple SQL statements made different
by the insertion of parameters. Thus, we would not want it to look too
much like the built-in print() function.
It will be up to the dbi writer to convert to the correct SQL dialect
for his specific flavor of SQL. I for one would do it happly for
adodbapi 3.0.
Also, DBapi 3.0 should follow the proposed python 3.0 standard that
all character strings are returned as Unicode, and all binary data
should be returned as data type 'byte'.
--
Vernon Cole
------------------------------------------------------------------------
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
