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 at python.org
>http://mail.python.org/mailman/listinfo/db-sig
>
>
Thank you all,
Art Protin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070531/3e8f91a3/attachment.html