Re: API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)
Michael Bayer <[email protected]>
| Newsgroups | gmane.comp.python.db |
|---|---|
| Message-ID | <[email protected]> |
On May 17, 2013, at 12:46 PM, "Vernon D. Cole" <[email protected]> wrote: > One of the things I like about Python is that I do not have to declare my data types in advance, as long as I use them correctly. I _like_ the idea of not having to pre-set my parameter style. (Having a mix of styles in one SQL statement is just wrong and need not be considered.) > > Having said that, if a module wants to support more than two -- which may often be the case -- there _must_ be a way to do the pre-set. > > So what if pre-sets were optional, and automatic selection based on parameter characteristics were the default? > > I could easily add that to my existing code by auto-switching when I see connection.paramstyle == NotImplemented. If anyone (like Danielle or myself) wants to continue supporting odd-ball paramstyles (i.e. anything other than the approved pair) then use an appropriate pre-set. If connection.paramstyle == None then hand it straight to the engine without looking. If one of the (previously defined) standard values, then reformat as needed, if needed. > > I am not trying to complicate a version 3 api -- but I also do not want to support two code bases -- so I want my version 3 module to be able to do anything my version 2 module does, including handle (newly deprecated or version specific) parameter styles. But I want that old behaviour to be optional. Think of a "from __past__ import paramstyle" feature. ;-) you'd never need to support two entirely separate codebases. There's many ways to have an API present two different facades, calling down to a common set of functions. We're only talking about facades here. _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig