[Python-Dev] draft pep: backwards compatibility

[glyph at divmod.com]

On 07:06 pm, python at rcn.com wrote:
>Not sure why we need yet another pep on the subject.  Just update PEP 5 
>if needed.

Hmm.  This is a good point; it might make sense to have a more specific 
PEP for library compatibility as opposed to language compatibility 
though, since language compatibility is necessarily a vaguer concept.
>Also, I think there is a certain amount of wishful thinking here. 
>Ideally, we could approve a tiny PEP with just a few bullet points and 
>it would eliminate the need for all of the complicated decision making 
>that we usually go through.  Ideally, we could make all decisions in 
>advance of seeing the facts for a given situation.  ISTM, this pep is 
>wishing away the actual complexity of making software design decisions.

This is not about making design decisions.  This is about how to treat 
the *output* of design decisions.

A really important part of this PEP, as I alluded to previously, is the 
part that tells developers what *they* should be doing if they want 
their python code to function on the next release of the interpreter.

Right now, the rule to write software that will not break with the next 
Python release is "read the minds of the python core committers and hope 
that you do not do anything with the stdlib that they don't like". 
Along with this there are several rules you can infer that are probably 
true most of the time: don't call stuff starting with "_", don't monkey- 
patch anything, don't use dynamic class replacement on objects from 
classes other than your own, don't depend on the depth of inheritance 
hierarchies (for example, no ".__bases__[0].__bases__[0]"), make sure 
your tests run without producing any DeprecationWarnings, be mindful of 
potential namespace conflicts when adding attributes to classes that 
inherit from other libraries.  I don't think all these things are 
written down in one place though.
>Another sticking point about preserving features across releases arises 
>if the feature itself is hazardous in some way (like have a security 
>hole or some such).  The contextlib.nested() function was an example. 
>(...)
>We resolved the question after a long and thoughtful discussion; I 
>don't think that decision making process could have been solved in 
>advance by a bullet-point in a general purpose process PEP.

You are correct that nothing in Python's policy could have dictated how 
this problem could be resolved.  However, the policy can most definitely 
state how to deal with code using contextlib.nested in the interim 
before it has been changed to use the new syntax: to wit, that 
contextlib.nested has to stick around, continue to do the (broken) thing 
that it did before, and emit a DeprecationWarning indicating the new 
syntax.  The existing policy in PEP 5 already does this, but doesn't 
offer guidelines on *how* to do this for lots of different types of 
changes.  For example, how do you issue a deprecation warning for a new 
parameter you want to require application code to accept?  How do you 
change the name of a parameter, to wit, do you need to expect that all 
arguments can validly be used as keyword arguments?  How do you 
determine an appropriate stack-depth, etc?