On 18 Mar, 07:53 pm, [EMAIL PROTECTED] wrote:
My second observation is that there seems to have been a lack of
people skills all around. That is perhaps to expect in a community of
geeks, but given the length of the previous thread on this topic
(before Martin checked it in) I think all the participants might have
done wiser by taking each others' feelings into account rather than
attempting to relentlessly arguing the technical point at hand.

Let me take the opportunity to make this clear, then. I have the utmost respect for Martin and his contributions for Python. I have been following commits for quite a while and I know that Martin, in particular, is often the one who deals with the crap work of reviewing huge piles of orphaned patches and fixing piles of minor issues, and he is therefore responsible for much of the general upward trend in Python's overall quality in the last few releases. I appreciate that very much.
My first observation is that this is a tempest in a teacup.

On the one hand I agree. This particular change is trivial, most likely doesn't affect me, and I accept that, in practice, it probably won't even break too many programs (and may even fix a few).

On the other, I think it is important to quell the tempest before it exits the teacup. Previously in this discussion, both I and PJE have repeatedly declared that this _particular_ change is not really what's at issue here, merely the pattern of reasoning that comes to consider this change acceptable. At some point a large number of small breakages are actually worse than one big one, and it's hard to point to the exact place where that happens.

On the gripping hand, I am almost glad that it was a relatively minor change that triggered this avalanche of posts. Even with such a small change, the change itself threatens to obscure a larger issue, and if the change itself were any bigger, it would eclipse the other discussion completely.
My third observation is tha a policy that would have disallowed or
allowed (depending on your POV) this particular change is not an
option. A policy isn't going to solve all disagreements, there will
always be debate possible about the interpretations of the rules.
What's needed is a way to handle such debate in a way that produces an
outcome without wearing everyone out.

The allow vs. disallow issue is not *really* what the policy should be addressing. A major problem with this thread is the differing definitions that some people have, beginning with "extension", but I can't see that a policy will fix *that*. Words like "bug", "fix", "compatible", and so on, all have "obvious" general meanings but much more nuanced and specific meanings in particular contexts. A policy should outline specifics of what, for example, is to be considered an "incompatible" change, and what must be done in that case. A policy could not outright forbid changes of a certain type, since that is pretty much asking that it be broken any time a sufficiently important change is requested and the core team likes it.

Maybe "policy" isn't even the right word here, since the part of it that would facilitate discussions like this one would be more "lexicon" than "policy".
It's important that the participants in the debate respect each other
-- before, during and after the debate.

Agreed.

Any "lack of people skills" notwithstanding, I hope I haven't said anything that implied (or stated, of course) that I did not *respect* the other participants of the discussion. If I have, I retract it. Strong disagreement is different than disrespect.
If you want, I can make a decision. But I will only do that if I hear
from both sides of the debate that they are willing to accept my
choice even if it favors the other party. Can I hear agreement to
that? In particular; Phillip and Glyph, if I decide that Martin's
change is OK for 2.6, will you accept it and stop debating it and get
on with your lives? And Martin, if I decide that the change should be
rolled back, will you be okay with that?

I will certainly accept the decision. I don't *like* generating trouble on this mailing list, believe me. Once a BDFL pronouncement is made, further discussion is just generating trouble.

That isn't the same as *agreeing* with the decision, of course :-).

The important thing for me is not reaching a decision on this particular issue (or even a particular decision on this particular issue). It is that we achieve some kind of consensus around how backward compatibility is supposed to work "in the large" rather than in a particular instance. For those of you who don't think this issue is important in and of itself, consider the secondary consequence of this ruckus happening every time someone commits a potentially-incompatible change.

I would not mind if, for example, this patch were "grandfathered in" to the lack of any clear backwards compatibility policy, as long as similar future changes were subject to more up-front scrutiny.

Although I don't really think the API should be changed, I don't regard that as a point of contention. As I've said before, I have seldom used splitext, and I am not likely to start after this discussion ;). The optional-argument / emit-a-warning changes are both amenable to me.

As a first approximation of such a policy (I am seriously working on that pre-PEP, it'll be ready any day now...) "one release with a deprecation warning is always required for any deviation from previously-documented behavior, either in the docstrings or library documentation". If there are problems with the warnings system that make this strategy impossible, I would be happy to help fix them in any way I can. It has occurred to me in the last few days that this the two sides in this debate may *actually* be "Warnings suck" and "Warnings suck, but they're all we have".
This is an experiment for me as well; if you all would prefer me to
stay out of it, I will. I haven't made up my mind yet about the
technical issue, but I'm not interested in hearing the arguments
repeated; I've heard them all and just need to mull it over. Let me
know.

I think we've all had enough of the discussion for now, so I'd personally appreciate it if you'd offer a pronouncement and we can all just move on. I can continue working on that pre-PEP regardless of this resolution, and that will need a separate pronouncement anyway.

At least, I don't feel like I have anything useful to add to the discussion that hasn't already been said, by me or by someone else.

Thank you for stepping in.
_______________________________________________
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

Reply via email to