[Python-Dev] Proposal to revert r54204 (splitext change)
glyph at divmod.com
glyph at divmod.com
Mon Mar 19 05:37:37 CET 2007
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
>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
>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
>It's important that the participants in the debate respect each other
>-- before, during and after the debate.
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
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...
More information about the Python-Dev