[Python-Dev] draft pep: backwards compatibility
glyph at divmod.com
glyph at divmod.com
Sat Jun 20 19:55:28 CEST 2009
On 19 Jun, 09:08 pm, benjamin at python.org wrote:
>2009/6/19 <glyph at divmod.com>:
>>On 02:09 pm, benjamin at python.org wrote:
>>>2009/6/19 <glyph at divmod.com>:
>> What about side-effects, or exceptional conditions? What about
>>interactions with subclasses? (Changing a class in a library from
>>to new-style has serious repercussions, as MRO conflicts can result in
>>applications that subclass it.)
>I've added a little more about this to the PEP. See what you think.
Finally had a chance to take a look. It's a big improvement, certainly:
much more specific. Although I think I have a few quibbles with the
For one thing, I don't like the use of the word "reasonable". Everybody
thinks *their* exception to the rules is reasonable, but nobody else's
is. Besides, if the BDFL thinks a change is really reasonable, do you
think a PEP is going to stop him? :)
For another, I think it's actually a bit too strict, as worded. The
side-effects of a function includes the warnings that it emits; any
method-call can have side-effects, so you can't change an algorithm *at
all*. The only side-effects that I think are important are the ones
that get invoked on objects that an application gets to inject
somewhere, or inspect later via a public API.
The word "releases" also needs to be qualified. Most importantly,
minor-version and micro-version releases need to be described
Finally, the PEP should mention its participation in the universe of
compatibility process PEPs. It should describe its relationship to at
least some of PEP 3002, 291, 5, 6, 2, 3001, and 384.
>>My point is that triviality is a matter of perspective :).
>I understand. I think we will just have to provide guidelines for
>triviality and decide on a case by case basis.
A simple litmus test, or some examples, of triviality would be helpful.
>>the pile-on can still happen on python-list, but
>>only the results of the discussion will be announced on the
>I think that's a fine idea, but the PEP is dealing with policy as our
>mailing list infrastructure is now.
Hmm... well, maybe everybody should just run their tests against Python
trunk. The commits list is a reliable notification mechanism for
potentially incompatible changes ;-). Perhaps it would be good to
mention this specifically in the PEP? For example, "third party
projects may request that an incompatible change be reverted, by
providing evidence of tests failing on x.y+1 that passed on x.y, where
the code in question does not rely on any details not specified as
'public' in the section above"?
If more projects did this when there *was* a problem, then it would
actually be a lot easier to break the policy with confidence. With an
incompatible change, you could know, "we checked it in, and nobody
complained". Whereas right now is nobody complains it's more likely
that nobody is paying attention.
More information about the Python-Dev