[DB-SIG] API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)
Vernon D. Cole
vernondcole at gmail.com
Fri May 17 18:46:42 CEST 2013
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. ;-)
On Fri, May 17, 2013 at 4:57 PM, M.-A. Lemburg <mal at 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 <mal at 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
> > 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
> 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
> 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 ...
> ::::: 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG