[DB-SIG] paramstyles, again
aprotin at research.att.com
Fri Jun 1 15:34:06 CEST 2007
Carsten Haese wrote:
>On Thu, 2007-05-31 at 10:44 -0400, Art Protin wrote:
>>I guess I am expected to weigh in and make perfectly clear where I
>"Expected" may be too strong a word, but yes, input from as many
>interested parties and API module maintainers as possible is helpful to
>If I summarized that correctly, you are in favor of requiring qmark,
>named, and numeric, and dropping format and pyformat.
>I could live with that. As I said before, InformixDB already supports
>all three styles, so whether named/numeric are optional or required
>makes no difference to me. I'm concerned that requiring named/numeric
>might encounter more resistance than requiring qmark, but so far I
>haven't seen such resistance on this thread.
>>As for a switching requirement: how does this sound (I just though of
>>it this morning)
>>making the parameterstyle depend on the first character of the SQL
>>If it is a colon, remove it and the parameter style is either numeric
>>or named; if it is
>>not a colon, the parameter style is qmark.
>Sorry, I give that a -1. Using "magical characters" is utterly
>unpythonic, and somebody reading the code would have no clue what's
>A sensible switching mechanism should look something like this, in my
>opinion: Add optional 'paramstyle' keyword arguments to
>module.connect(), connection.cursor(), cursor.execute() and
>cursor.executemany(). In the absence of a 'paramstyle' argument,
>individual executions inherit the cursor's paramstyle, cursors inherit
>the connection's paramstyle, and connections use the module's read-only
>paramstyle attribute as default. (As discussed before, allowing the
>module-wide paramstyle to be changed is IMO a bad idea.)
First, I must confess. I do not know how to make a module's attributes
I do know how to make classes where object instances have read-only
Optional keyword arguments are a very good approach & I do like the
inheritance scheme. Would it make sense for paramstyle to be an attribute
of connection and cursor, that could be read and written?
(As for changing the module-wide paramstyle, you have persuaded me that
that approach is "sub-optimum". I do expect that I will at least have
a superior way and change the documentation to point users at the better
>Then again, I'm not too excited about the whole idea of manual
>switching. I'd prefer auto-detection based on whether the query string
>contains question marks, colon+number or colon+identifier markers
>outside of string literals. Not only because that is what InformixDB
>already does, but because it leads to cleaner code.
I would like autodetection, even prefer autodetection, if I was sure
that it would
work correctly every time no matter what. I am getting more comfortable
that hypothesis, but have not yet developed a proof that autodetection
In absense of such a proof, I prefer to have the user (even when that
user is me)
declare what is expected and have the module check as best it can and
when the expectations are not met.
If such a proof was included in the spec., then .paramstyle could be
(and that would be good).
[[ why does my email agent seem to discard your signature ??? ]]
Thank you all,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG