On 2007-06-04 13:17, Carsten Haese wrote: > On Mon, 04 Jun 2007 10:41:46 +0200, M.-A. Lemburg wrote >>> We still need to settle the question of what to do about numeric and >>> named styles. There is some support for making both styles mandatory and >>> expecting the API to automatically discern from the query string which >>> parameter style is in use. >> I don't think that this is such a good idea and I'm also not sure >> how you'd do that: what if a programmer mixes the two (or three) >> styles by mistake ? How would the programmer test whether a >> module supports this automatic detection scheme ? > > If the programmer mixes incompatible parameter styles, the implementation can > choose to handle it gracefully (sqlite3) or raise an exception (InformixDB). > InformixDB actually allows mixing qmark and numeric in a straightforward way: > The first question mark is equivalent to :1, the second question mark is > equivalent to :2, etc. Only mixing positional markers and named markers raises > an exception. > > I'd be okay with throwing an exception in any case of mixing, but I don't know > how that would sit with sqlite3. > > The test for whether the module supports the automatic detection is > module.apilevel=='3.0'.
Do you really think it's reasonable to have the module parse every single SQL statement just to detect the param style ? What happens if you're in qmark style mode and the SQL statement contains substrings which look like named style (but are not intended that way, e.g. think stored procedures) ? This approach also contradicts the explicit is better than implicit Zen rule. Just so that there's no misunderstanding: you're free to implement this sort of extension in your module(s), but making this mandatory in the spec feels wrong. I tend to view this whole discussion as a bit off the track: In an API specification, you normally define one way which all implementations have to follow, not multiple ways of doing the same thing in slightly different ways. >> There's also the problem of parameter type if we allow named >> style. The parameters would then have to be dictionaries for >> named and tuples for qmark/numeric. So you effectively change >> the signature of the .execute() methods based on a parameter >> which is not good style. > > I disagree. It's duck-typing. Following you proposal to require auto-detection, this would mean more than just duck-typing. You wouldn't know what type to expect until you've parsed the SQL statement string - ie. when you're already inside the .execute() method and passed the argument parsing step. That's a bit much too dynamic and too implicit for an interface specification. So I'm: * +1 on making support one param style mandatory for all implementations * +1 on requiring an interface to adjust the param style on a per connection or even per cursor basis, so that it's easy to setup an implementation to the mandatory param style (in case the module defaults to another param style for backwards compatibility reasons) This interface would have to support at least the mandatory param style. * -1 on doing auto-detection of param styles at .execute() call time based on parsing the SQL statement -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 04 2007) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
