[DB-SIG] paramstyles, again

[Carl Karsten]

Carsten Haese wrote:
> On Mon, 2007-06-04 at 15:00 +0200, M.-A. Lemburg wrote:
>> Well, no: I'm saying that it's not a good idea to have the
>> signature depend on a parameter.
>>
>> OTOH, you need such a parameter to allow programmers to query
>> the current paramstyle setting, if you do allow multiple param
>> styles.
>>
>> This creates a conflict.
>>
>> The only way around it would be to say that the 'parameters'
>> parameter in .execute() must have a __getitem__ compatible
>> interface which is then used to either get the positional
>> argument (via an integer key) or the named argument (via
>> a string or Unicode object).
> 
> I'm not sure I follow. The proposal on the table is to require all
> interfaces to support qmark, numeric, and named, and to automatically
> detect from the query string which style the query uses. Since the
> programmer controls both the query string and the corresponding
> parameters, there is no use case for inspecting the current paramstyle
> setting.
> 
> To me, there is no practical difference between saying "the parameters
> argument is a sequence or a mapping as determined by the query's
> parameter style" and "the parameters argument may be any object with a
> __getitem__ method that provides appropriate keys", so I'm fine with
> either one as long as that gives us auto-detection of parameter styles.
> 

Is auto-detection that important?

So far it seems the main (only?) reason for 'auto' is because no one has come up 
with a good way of specifying it as a parameter.

I think I saw a good reason for supporting multiple paramstyles, but maybe the 
agreed upon points is should be put on a wiki.

I have this 'feeling' that if the multiple paramstyles 'requries' auto 
detection, it isn't worth it and would be better if we just picked a single 
paramstyle.  I can't really see why any one single paramstyle would not be 
useable in all cases.

Of qmark, numeric, and named, I think named is the best of all worlds.  I think 
if that was the only choice, life would be pretty good.  Would adding the others 
make life any better?  especially considering the 'cost' (complexity:  more code 
in dbapi modules, more than one way to do things, more docs, more time in dbapi 
tutorials...)

I vote for named only and get rid of the whole paramstyle issue.

Carl K