[Python-Dev] draft pep: backwards compatibility

[Antoine Pitrou]

<glyph <at> divmod.com> writes:
> 
> In order for any changes to be possible, there needs to be a clearly 
> labeled mine-field: don't touch or depend on these things in your Python 
> application or it *will* break every time Python is released.

I think the "frozen area" should be defined positively (explicit public APIs and
explicitly guaranteed behaviour) rather than negatively (an explicit "mine
field"). Otherwise, we will forget to put some important things in the minefield
and get bitten later when we need to change those things in a
backwards-incompatible way.

For example, I think it was wrong to change the name of a test-skipping unittest
method just so that it wouldn't clash with a method created by Twisted
subclassing unittest (besides, self.skip() was much nicer than self.skipTest()
;-)). Just because some class is public shouldn't prevent us to add new public
methods or attributes to it.

Regards

Antoine.