<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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
