
On 07:06 pm, python@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?