[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)
mike_mp at zzzcomputing.com
Fri May 17 18:57:21 CEST 2013
On May 17, 2013, at 12:46 PM, "Vernon D. Cole" <vernondcole at gmail.com> 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.
More information about the DB-SIG