[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

[Michael Bayer]

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.