[DB-SIG] paramstyles, again

[Art Protin]

Dear folks,
    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
>>stand.
>>    
>>
>
>"Expected" may be too strong a word, but yes, input from as many
>interested parties and API module maintainers as possible is helpful to
>measure consensus.
>
>  
>
>>[snip...]
>>    
>>
>
>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
>>statement.
>>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
>going on.
>
>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 
read-only.
I do know how to make classes where object instances have read-only 
attributes.

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 
to add
a superior way and change the documentation to point users at the better 
way.)

>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 
with
that hypothesis, but have not yet developed a proof that autodetection 
could not
get spoofed.

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 
complain
when the expectations are not met.

If such a proof was included in the spec., then .paramstyle could be 
eliminated
(and that would be good).

>Best regards,
>
>  
>
[[ why does my email agent seem to discard your signature ??? ]]

    Thank you all,
    Art Protin




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070601/eab0813b/attachment.htm