Carsten Haese wrote: > 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 totally disagree, and have a feeling this needs to be voted on before either of us can continue this discussion. I propose that pep 249 is the only document that we should be considering. What happens if docs and pep 249 conflict? > >>>> 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. That seems inconsistent with your definition of backwards compatible. "won't break" is not "may or may not be guaranteed to work" I am glad that you are willing to let some code "not be guaranteed to work" or am I misunderstanding? > > 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. > Do you consider the module source code part of the documentation? >>> 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." It doesn't need to. "use this" does not include the option of "use something else." > >> 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. > My single interpretation isn't whats important. The super set of possible interpretations is what needs to be considered when trying to maintain compatibility. My point is that the pep, and probably some of the docs you want to rely on, isn't crystal clear, so compatibility may be impossible. >> 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. That doesn't mean we can't compromise more. > Backwards compatibility should only be broken if there > are very convincing reasons to do so. I believe 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. Only if they follow the spec. I bet you won't find anything that says a programmer can rely on paramstyle not changing. Which means all code, even db specific code, should be using paramstyle when creating parameters, and should be able to function using any of the 5 v2 values. > >> 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 am pretty sure we should not try to rely on what "The programmer just knows" You may want to reword that using words like pep 249 and "look at the modules source code." >> 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 think you mis understood what I meant. >>> import MySQLdb >>> MySQLdb.paramstyle 'format' What if in the next version of MySQLdb stopped using 'format' and on used 'qmark'? I am sure lots of code would fail. I know lots of my code would fail. Personally, I think the pep allows it to change. >>>> 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. I can write code that will work today and break under your proposal: .paramstyle='named' .execute( "select * from foo where fid = ?", (1,) ) I have no desire for code like this to continue working. Do you? Admittedly, this probably does not exist, but I think it is enough to show that "ALL v2-based application code out there" needs to be better defined. Unless you somehow think the proposal needs to be updated to somehow allow this. >>> >> 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. > Backwards compatibility: Applications that follow the official specs don't break. Pretty sure Pep 249 is the only spec I would consider official, but I am open to suggestions. Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
