On Tue, 2007-05-22 at 09:22 -0400, Art Protin wrote: > Initially I also saw the .paramstyle as providing the implementor too > much freedom. > > However, I chose to take it as a challenge. In my > implementation, .paramstyle is not > read-only but read-write and all of the defined styles are accepted. > In fact, once I > figured out how to handle the parsing of SQL comments & literals, > parsing of any > style of parameters was almost trivial (I had to do that parsing in > Python due to the > nature of our system). [Actually, I had to add code to block the > styles "pyformat" > and "format" because my boss agreed with Carsten, although he would > have preferred > that I removed code.] > > In my opinion (which is never as humble as it should be), "qmark" is > barely adequate; > numeric should be the required minimum. But now that so many have > gotten used > to "qmark", it will probably never go away. > > I am glad that the spec. [PEP 249] did not require that .paramstyle be > read-only and > now oppose any attempt to "correct" that oversight.
Making the module's paramstyle writable is an odd approach. If you have one function that needs one style and another function that needs another, each function will have to explicitly set the module-level paramstyle attribute before executing the query, for fear that another function might have changed it in the meantime. That faint screaming you hear in the distance is thread-safety being thrown out the window. As an example of an alternative, InformixDB allows qmark, numeric, and named parameters, and execute() recognizes on the fly which one you're using. The paramstyle attribute only "advertises" numeric, because there is no way to advertise all supported styles while remaining compliant with the spec. qmark may not be adequate in your opinion, but it has the advantage that it's SQL standard, as far as I know. Hence, it's the parameter style that's most likely to be a native parameter style in commercial SQL implementations. If we made qmark mandatory, application developers could rely on the fact that at least qmark style will be supported. Allowing additional parameter styles, either recognized on the fly by execute(), or given as a cursor attribute, or given as an optional argument to execute(), should be encouraged, but not required. This has been discussed before, but I'd like to re-cast a vote on this for DB-API 3.0: * Deprecate/disallow pyformat/format paramstyles. * Make qmark the mandatory minimum paramstyle. Allowing additional parameter styles (numeric and/or named) would be optional and implementation specific. Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
