
On 19 Jun, 09:08 pm, benjamin@python.org wrote:
2009/6/19 <glyph@divmod.com>:
On 02:09 pm, benjamin@python.org wrote:
2009/6/19 �<glyph@divmod.com>:
�What about side-effects, or exceptional conditions? �What about interactions with subclasses? �(Changing a class in a library from old-style 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 wording. 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 distinctly. 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 incompatible-announce list.
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.