
On 02:09 pm, benjamin@python.org wrote:
2009/6/19 <glyph@divmod.com>:
On 02:17 am, benjamin@python.org wrote:
I've taken a stab at this myself in the past while defining a policy for Twisted
Yes, that's helpful. Thanks.
Glad you found it useful.
The questions that follow might seem satirical or parodic but I am completely serious and each of these terms really does have a variable definition.
And will always no matter what we do. It's how natural language works.
Well, one cannot proceed from the informal to the formal by formal means. I'm pretty sure we can nail down the definitions of these terms for the scope of Python core development.
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.)
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.
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. The point is, the notifications about compatibility are really important, and sometimes people need to offer feedback about them, but not everyone who needs to know about the changes needs to hear about the feedback.