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. I would suggest that requiring every implementation to support every kind of parameter passing is a large step in the wrong direction. 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. ;-) 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
