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

[Carl Karsten]

Carsten Haese wrote:
> On Wed, 20 Jun 2007 22:59:18 -0500, Carl Karsten wrote
>> "super simple" would be the new api.   pretty easy is the wrapper 
>> for backwards computability.
>>
>> As complex as that set would be, it wouldn't be much worse than the 
>> current mess.
> 
> That's why we're discussing an improvement. The current proposal on the table
> is this:
> 
> * Every API implements at least qmark and named.
> 
> * APIs are allowed to implement other styles.
> 
> * Connection and Cursor objects have a writable paramstyle attribute to choose
> which paramstyle to use. The default is implementation-defined. Possible
> settings are implementation-defined but must include at least qmark and named.
> 
> 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.

> 
> You're welcome to try to come up with a simpler solution that has the same
> advantages.

I did before: "only allow one style of parameter."  But it got out voted, (or 
not even on the ballot) and so I won't push for it anymore.

  >>> numeric -1
  >>> format -5
  >>> pyformat -2

To me that reads "remove them."  0 would have been "tolerate them."

However, I can see that if there was at least one parmstyle that was consistent 
across all APIs (like we are all in agreement on), no one in their right mind 
would use one of the non-standard ones.

Carl K