On May 17, 2013, at 12:46 PM, "Vernon D. Cole" <vernondc...@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. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
