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