[Python-Dev] Proposal to revert r54204 (splitext change)

[glyph at divmod.com]

On 18 Mar, 07:53 pm, guido at python.org 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070319/e8ae87ff/attachment.htm