Carsten Haese wrote:
> On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
>> When we talk about backwards compatibility, I am wondering exactly what that
>> means.
>
> A module is backwards compatible if code using it won't break if the
> module is replaced with a newer version.
Even if it relies on implementation details?
If so, then I don't think "backwards compatibility" is something worth
bothering
with, and we need to figure out a term for what we do want to be bothered with.
>
>> I think my question is: should code that does not follow the dbapi2 spec be
>> guaranteed to work?
>
> That's a completely different question.
Given your above definition of backwards compatible, it seems to be the same.
How is it different?
How would you answer it?
>
>> For instance, I know some of the dbapiv2 modules support more than one
>> paramstyle, yet the spec really only allows the one defined by .paramstyle.
>> So
>> if application code uses some other paramstyle, does backwards compatibility
>> mean the application code should still work?
>
> Yes.
How would the application and/or developer know what other styles will work?
> The module-wide paramstyle attribute only means "If you use this
> paramstyle, it's guaranteed to work." It doesn't mean "This is the only
> paramstyle that works."
paramstyle
String constant stating the type of parameter marker
formatting expected by the interface.
To me "expected by the interface" means "use this." I will admit that one line
does not define it well, but that fuzzyness makes it hard if not impossible
to
guarantee compatibility. guarantee would mean "compatible with anyones
interpretation.' I considered "reasonable interpretation' but realized that
hinges on someone defining reasonable, which does not seem to fit with
"guarantee." I am pretty sure in the end, reasonable compromises will have to
be made, which implies "maybe we are breaking compatibility."
>
>> To me, the dbapi2 paramstyle 'spec' was so poorly defined that it is
>> impossible
>> to be compatible with it and implement some of the changes we are
>> considering,
>> regardless of how big the backwards compatibility umbrella is.
>>
>> I tried to write code once that made use of paramstyle:
>>
>> x='MySQLdb'
>> dbapi=__import__(x)
>> if dbapi.paramstyle= ...
>>
>> and gave up.
>
> Well, the new version will allow you to pick either qmark or named and
> run with it.
>
> x = 'informixdb'
> dbapi=__import__(x)
> conn = dbapi.connect(dbname)
> conn.paramstyle = "named"
> # ...
>
> Without the explicit paramstyle assignment, the connection will just
> default to whatever the v2 implementation used so that applications
> remain compatible.
Where does it say a modules paramstyle could not be changed across revisions?
I am starting to think paramstyle has been used like documentation, and there
is
something just wrong about that.
I do not think that code that relies on paramstyle being a certain value should
be expected to work.
>
>> I am wondering if there is really _any_ code out there that can survive
>> paramstyle changes.
>
> If we make the change as proposed,
Can you tell me exactly what is proposed? I'm not sure the various posts to
the
list can be cited as a proposal. I really think we need to make use of some
wiki pages. Or maybe I am the only one that thinks things are far from crystal
clear.
> and the modules implement the change
> correctly, ALL v2-based application code out there will survive the
> change. After all, that's what backwards compatibility means.
>
My point was some definitions of backwards compatibility may not be a
worthwhile
goal.
Carl K
_______________________________________________
DB-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/db-sig
