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

[Art Protin]

Dear folks,
    Carsten Haese wrote:

>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.
>>    
>>
So, we exist to write code.

>>More complex API.
>>    
>>
We should write more complex implementations if that means that
the applications for our code can be made less complex.

>>More complex application code.
>>    
>>
How can it be any more complex than what we already have,
namely, having to adjust the SQL queries to match the supported
paramstyle.

>
>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.
>
>  
>
I believe that there is more wisdom in enabling  others to do the "right 
thing" than in
requiring them to do the "right thing" .

Furthermore, I do not see how users of my interface will be able to 
write much
portable code.  Our SQL does not have any support for querying "system 
tables",
the specification does not provide methods for defining persistant named 
queries
(like those invoked by callproc()), and the specification does not 
provide any
support for non-SQL queries, so I have to extend the interface far 
beyond what
the specification covers.

Maybe, API v8 will permit truely portable code or then again maybe not 
until v18.

Going to requiring some set of paramstyles is another step toward enabling
applications to be written portably.

>> > 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.
>
>  
>
Maybe not initially but that seemed to me to be to be all that it came 
to cover.

>>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.
>  
>
I am sorry to have to say that I frequently overstate my case.

Forbidding paramstyles that were not required would be better in a new 
interface,
however, breaking application code that uses the current interface is 
too much to
pay for such an "upgrade".  (I hope that this helps refine my position 
and moves
us closer to "harmony".)


    Thank you all,
    Art Protin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070622/166fc01e/attachment.htm