[Python-Dev] draft pep: backwards compatibility

[Terry Reedy]

glyph at divmod.com wrote:

> 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.

I agree. The draft covers the same ground. Two PEPs on the same subject 
would be redundant where they agree but would  create confusion where 
they do not.

To the extent that the new PEP intends to change existing policy by 
severely curtailing language change, as it appears to, then that *idea* 
should be directly presented and discussed, perhaps on python-list, 
before worrying about wording (bikeshed) details.  In other words, I 
think the discussion should have start out "Here is existing policy (PEP 
5).  I propose to change it like so..." or possibly "Here is existing 
policy in PEP 5. I believe it has defacto changed as evidenced by ... "

In other words, discuss and decide whether the bikeshed should be 
re-painted before worrying about the exact shade.

> 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".

A bit harsh ;-)

> 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.

This could be the core of a new PEP Keeeping up with Language Changes.
I think that would be a good thing.

Terry Jan Reedy