[DB-SIG] spec: named parameters: clarification needed

[Matthew T. Kromer]

M.-A. Lemburg wrote:

> [... lots of thread deleted...]


>
> I'm definitely -1 on changing the spec to make it more
> inconsitent. It has been around for a long time and proven its
> usability. I also don't think that the paramstyle idea was
> a good one and would rather like to go back to a sane single
> parameter style standard for DB API 3.0.
>
Well, I tend to agree with Anthony that I like to have drivers that are 
maximally flexible towards the intent of the user; certainly the DB API 
2.0 spec could use a lot more examples to demonstrate that when it uses 
a single word in a signature, it really means a single word (again, 
semantic choices).

For my part, I encourage folk to write

    c.execute(statement, arg1, arg2, ..., argn)

over

    c.execute(statement, (arg1, arg2, ... argn))

because I find the extra pair of parens to be nonobvious and I prefer to 
use *args in the method signature to slurp up all of the extra 
arguments.  This isn't API 2.0 compliant, but it is the intuitive call 
format.  DCOracle2 sniffs the arguments to see if they are being passed 
in a DBAPI 2.0 mode, DBAPI 1.0 mode, or what I consider the "intuitive" 
mode.

Spec purists and I will probably agree to disagree over this.  To my 
mind, the only danger is those who assume that their code is 
automatically portable -- but those same folks are just as likely to use 
nonportable SQL anyway (for example, I love Oracle's "CONNECT BY" 
clause).  Ergo, the onus is on the user to write portable code.  Caveat: 
 I would be acceptant of some type of handshake the invoker could do to 
say "enable driver extensions" which would assert that the code was 
allowed to use non-standard modes.

I also don't see any way to move to a unified single argument format, 
short of using helper methods to construct queries. The notion of 
writing SQL thru lots of tiny methods is not one I find attractive -- 
it's like the folks who used to spend days constructing HTML helper 
methods so you could call helper.br() to emit "<br>" (I'm sure everyone 
remembers those classes!)