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. > I think my question is: should code that does not follow the dbapi2 spec be > guaranteed to work? That's a completely different question. > 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. 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." > 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. > I am wondering if there is really _any_ code out there that can survive > paramstyle changes. If we make the change as proposed, 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. -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
