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. ;-) -- Vernon Cole On Fri, May 17, 2013 at 4:57 PM, M.-A. Lemburg <m...@egenix.com> wrote: > On 17.05.2013 17:44, Vernon D. Cole wrote: > > On Fri, May 17, 2013 at 4:36 PM, M.-A. Lemburg <m...@egenix.com> wrote: > > > >> e.g. passing a > >> dictionary of parameters to a SQL command which uses a mix > >> of qmark and named style parameter markers. > >> > > > > That is a plain, simple syntax error, and will be reported as such by the > > SQL engine, along with a million other syntax errors that I have no way > of > > detecting in Python. The error reporting is the same in all cases: "SQL > > does not like your stuff." > > Not necessarily, since the database module will likely convert > the SQL to one of the two param styles, so you end up with > a SQL string that contains both the converted param markers > and the ones you had in the original SQL string. > > Detecting the used paramstyle from the SQL statement is really > difficult, so modules would more likely used the parameter > object type to determine the paramstyle, but this also has it's > problems: > > For qmark, you'd look for a sequence, for named, you'd look > for a mapping. There are situations (e.g. in ORMs) where the > parameter object actually supports both interface types. > > Which brings us to "In the face of ambiguity, refuse the temptation > to guess." :-) > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, May 17 2013) > >>> Python Projects, Consulting and Support ... http://www.egenix.com/ > >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2013-05-07: Released mxODBC Zope DA 2.1.2 ... http://egenix.com/go46 > 2013-05-06 <http://egenix.com/go462013-05-06>: Released mxODBC 3.2.3 ... > http://egenix.com/go45 > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ >
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
