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
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
