
2009/6/19 <glyph@divmod.com>:
On 02:09 pm, benjamin@python.org wrote:
2009/6/19 <glyph@divmod.com>:
What is "behavior"? Software is composed of behavior. If no behavior changes, then nothing can ever happen.
I mean that if you pass X and Y into a function and get Z in 2.6, then you should be able to get Z from passing X and Y in 2.7 even if there's a new argument that returns Z' if you pass True to it. (Obviously, this is somewhat simplified, but I hope it helps.)
This definition only makes sense if the interesting thing about a function is its return value, and if the only sort of thing you have are functions. 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.
How do you propose to measure the benefit to breakage ratio? How do you propose to define "trivial" to fix? Most projects, including Python, Twisted, Django, and Zope, have an ever-increasing bug count, which means that trivial issues fall off the radar pretty easily.
Well, if you're tests aren't failing from it, is it an incompatibility?
Well, let's say the tests do fail from it. Right now, even Twisted trunk still doesn't *quite* support Python 2.6, but only on Windows, due to stricter checking of the 'mode' argument for files. But this failing test is just not that high priority, so our recommendation is "don't use python 2.6 yet on Windows, 2.5 works fine". My point is that triviality is a matter of perspective :). Eventually somebody will get around to it, but 2.6 has been out for a while now.
I understand. I think we will just have to provide guidelines for triviality and decide on a case by case basis.
There are a very large number of users of Python, the large percentage of whom do not read python-dev. A posting on python-list is likely to provoke an unproductive pile-on. I suggest a dedicated list, which should ideally be low traffic, "python-incompatible-announce", or something like that, so that *everyone* who maintains Python software can subscribe to it, even if they're not otherwise interested in Python development.
And that won't generate a pile-on?
Well, the etiquette for that specific list could be "keep this low- traffic unless you have a serious problem with this change". Or, better yet, make it an announce-only list: 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. -- Regards, Benjamin