Re: API 3.0 limiting paramstyle to ['named', 'qmark'] is okay. ('format' is not desirable)

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 <[email protected]> wrote:

> On 17.05.2013 17:44, Vernon D. Cole wrote:
> > On Fri, May 17, 2013 at 4:36 PM, M.-A. Lemburg <[email protected]> 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  -  [email protected]
http://mail.python.org/mailman/listinfo/db-sig