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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
