[DB-SIG] paramstyles, again (and now voting)

[Carsten Haese]

On Thu, 2007-06-21 at 09:14 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> >> Carsten Haese wrote:
> >>> The advantages are clear:
> >>>
> >>> * Application code written against this spec can be sure that named/qmark
> >>> styles are available, and there is a common API for choosing which one to use.
> >>> That means less API dependent code, and the overhead for choosing qmark or
> >>> named is minimal at one line of code per connection.
> >>>
> >>> * APIs aren't forced to abandon "legacy" parameter styles so existing code
> >>> written for existing APIs won't break.
> >>>
> >>> * No backwards compatibility wrapper is necessary.
> >> I do not see the last 2 points as a clear advantage, given the cost.
> > 
> > What cost? 
> 
> More code in the dbapi module.
>
> More complex API.
>
> More complex application code.

Compared to what? What's your proposal?

> Application code that uses non portable paramstyles,

So what? Application code may also use non-portable SQL language. Python
programmers are consenting adults, and if they want to write
non-portable code, let them.

>  > The one line of code per connection to explicitly choose
>  > qmark or named style?
> 
> no.  in fact I don't think that line of code is in the backwards compatibility 
> category.  backwards compatibility should use the dbapi v2 api, where paramstyle 
> is read only.  I envision changing "import MySQLdb" to "import MySQLdb_v2 as 
> MySQLdb"

I never said this line of code was for backwards compatibility. Under
the proposal on the table, backwards compatibility is achieved by doing
nothing to existing applications.

Forward compatibility is achieved by explicitly stating which parameter
style the application uses. That's that one line of code I'm talking
about, and, true, it will have to be inserted into every new
application, but your proposal requires changing every existing
application, and somehow you call that backwards compatible.

That's like saying diesel is compatible with a gasoline car as long as
you install a diesel engine into the gasoline car.

>[...]
> "it" was voted on and "it" was not really well defined.  This is the closest 
> thing I can find to what was voted on:
> 
> 
>  >>>  * +1 on making support one param style mandatory for all
>  >>> > >>    implementations
>  >> > >
>  >> > > Any one? Let's make named mandatory, then.
>  > >
>  > > I intentionally left this open  :-)
>  > >
>  > > We should have a vote on it. Let's gather votes for say two weeks
>  > > and then see what the outcome is.
> 
> Given that, I think what was decided via the vote was "make named mandatory" but 
>    I would not be surprised to see 5 posts saying "I thought I was voting on Xn"

The context made it clear to me that the "it" we're voting for was which
paramstyle to make mandatory.

> Personally, even though I favor the counts (?/name positive, rest negative) I 
> would like to see those votes discarded a more comprehensive, well defined round 
> of voting.

Sure, let's keep on voting until you are happy with the outcome.

>  > However, there is a lot of MySQL and PostgreSQL code out there
> > that would break if those styles were removed outright.
> 
> backwards compatibility wrapper.

And how does this backwards compatibility wrapper look? How does it
work? How does it achieve backwards compatibility without requiring
every existing application to be modified?

> Or just name the new module something new.  What is the down side to adding a 
> dbapi version number to the module names?

Existing application code would automatically and gratuitously lose
forward compatibility with future versions.

> "BUT I for one, strongly endorse forbidding whatever is not required
> in the the way of parameter styles (or at the very least dropping any mention of 
> any parameter style that is not required)" Art Protin
> 
> But his position may have changed, much like how strongly I feel about it.

It's one man's opinion, and he has a right to his opinion, but it is a
very unpythonic opinion.

-- 
Carsten Haese
http://informixdb.sourceforge.net