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

[Guido van Rossum]

On 3/18/07, glyph at divmod.com <glyph at divmod.com> wrote:
> 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.

Thanks.

> >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).

Then why was there such an upheaval when it was submittedd?

> 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.

I think you're missing my point here. At issue is a judgement call,
not an adjustment of the rules. Everybody knows that we fix bugs
mercilessly but are very careful with deprecating features. At issue
is the judgement about whether a particular changes is a bug or a
feature. I don't accept the position that since there are unit tests
and docs for it, it must be a feature; those could well have been
produced without much thinking and after the fact (I *know* they were
produced after the fact since splitext() long predates our first unit
test).

So if there's any new rule required, it's not a rule for defining more
clearly the definition of bug vs. feature, but a rule for what to do
if you disagree with a change (whether committed or proposed). But
that falls in the realm of human behavior, and I very much doubt we
can write a PEP for that. Even if we could, I really don't think I'd
like the result; I'm not into having a court of appeals or any such
formal solution.

To be concrete, I think that if Phillip had written a different kind
of post instead of the one where he requests the reversal of the
submit (only parenthetically mentioning Martin) then perhaps Martin
wouldn't have felt the need to dig in and defend his position, and the
issue might have been resolved quicker and at less emotional expense.
I see small discussions on python-checkins all the time where someone
comments on someone else's checkin, and the tone of the comment makes
all the difference.

> 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.

One recommendation I have for discussions like this (thanks to Stephen
Turnbull in private mail) is to attempt to separate in your mind (and
in everyone's mind) the distinction between the change at hand and the
policy discussion. Muddling these two together makes for a poor
discussion of the feature and an even poorer discussion of policy
change.

> >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.

IMO all the policy we need is PEP 5. It wisely defers to common sense
regarding the implementation, and that's where I want to re-focus the
discussion.

> 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".

The crux is in trying to define "major". That's vague, and
intentionally so; I think it would be a mistake to try to define it
more properly for all time. The Python community changes over time
(remember the features I added in 1.5.2? Or even as late as 2.2.3? :-)
and I would much rather spend time understanding what's most important
for the rank and file users at this moment than debate the fine points
of a word's definition amung ueber geeks.

> >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 :-).

And that's my point. There were plenty of people who didn't agree with
the @decorator syntax at the time (or with print >> file, or any
number of examples); but they didn't bear a grudge. One or two even
said specifically "I disagree with the feature but I will continue to
use Python".

> 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.

And here I disagree. I think our backward compatibility *policy* is as
good as it gets; how we address the importance of a judgement call in
a particular case is not.

> 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.

I'm trying to stay out of the feature discussion, but I would like to
point out that a policy that, in the sake of some strict definition of
backwards compatibility, forces us to introduce new APIs (or new
optional parameters to existing ones, which is really the same thing)
at a high rate is also doomed to have an overall detrimental effect on
the language -- who know, perhaps more so than the occasional
incompatible change.

> 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".

We already have that policy in PEP 5. Except for the anal definition.
Which is wrong too -- if a feature happens to be undocumented that
still doesn't make it fair game for a sudden incompatible change.

> 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.

As you see I'm trying to discourage you from working on such a
document; but I won't stop you and if there's general demand for it
and agreement I'll gladly review it when it's ready. (It's a bit
annoying to have to read long posts alluding to a document under
development without being able to know what will be in it.)

But I won't make up my mind yet; I'm still waiting hear from Phillip.

> 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.

Well, I just hope my contributions *are* useful.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)