On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote: > 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?
Yes, if those details are documented. Otherwise, no. > >> 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? The question is incomplete. Code that does not follow the spec may or may not be guaranteed to work depending on whether it uses implementation details that are documented. For example, InformixDB allows the programmer to freely mix parameter styles. The spec doesn't say that this is allowed, and it doesn't say that it isn't allowed. The feature is outside the spec, but the documentation for InformixDB says that it is allowed, and programmers using the module have a reasonable expectation that it will continue to be allowed in later versions of InformixDB. > > > >> 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 application wouldn't need to know this, and the developer would know this at least from the module documentation. We may decide on introducing another module attribute called paramstyles or whatever that lists the allowed styles. > > 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." Exactly. It doesn't say "use ONLY 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.' Well, if your interpretation is "I MUST use this style", you're not going wrong. If you use the style that's indicated, it's guaranteed to work. Whether other styles are accepted is implementation defined. > 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." We have reached a compromise, and it doesn't involve breaking backwards compatibility. Backwards compatibility should only be broken if there are very convincing reasons to do so. > >> 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? It doesn't, but programmers have a reasonable expectation that their code works from one version of a module to the next. > I am starting to think paramstyle has been used like documentation, and there > is > something just wrong about that. In database-specific code, paramstyle isn't used at all. The programmer just knows what parameter style to use. Database-independent code needs to inspect paramstyle and build queries to fit. > > I do not think that code that relies on paramstyle being a certain value > should > be expected to work. I have never seen code that relies on paramstyle being one certain value, so you're talking about an empty set. I agree with the statement in so far as I also agree that flying pigs shouldn't eat cheese. > > > > >> 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. Please allow me to repeat verbatim from a post I made earlier today: """ 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. """ You responded to it, so I assumed that you have read it. > > 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. Applications not breaking randomly when a module is upgraded is a worthwhile goal. I don't know what other definition of backwards compatibility you're using that makes backwards compatibility not a worthwhile goal. -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
