On 19 Jun, 09:08 pm, benja...@python.org wrote:
2009/6/19 <gl...@divmod.com>:
On 02:09 pm, benja...@python.org wrote:
2009/6/19 �<gl...@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.
_______________________________________________
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
