[Python-Dev] Proposal to revert r54204 (splitext change)
Phillip J. Eby
pje at telecommunity.com
Mon Mar 19 17:28:44 CET 2007
At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote:
>This is an experiment for me as well; if you all would prefer me to
>stay out of it, I will.
With respect to the specific change, it seems to me that there is an
emerging consensus for adding keyword arguments to support the new
behaviors, so I'm not sure a pronouncement is needed. As far as I'm aware,
the main question left open is whether the default behavior should change
in a future version of Python, and if so, which version.
>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.
Martin's position was already abundantly clear; the fact that he had
checked in the change despite prior opposition demonstrated that a personal
appeal was already moot -- the "digging in" had already taken place a week
or two prior, when the use cases were first presented and objections were
first raised, and Martin simply dropped the discussion and checked it in
anyway. He left my last message in that discussion (laying out a detailed
rationale for rejecting the change) without a reply:
So I was absolutely stunned when I found the change had been checked in,
To be concrete, if Martin had spent less time trying to discredit and
discard the use cases of the people being "polled" about the question, a
compromise could perhaps have been reached *before* he applied the patch,
and the second discussion would never have needed to happen.
In other words, the second discussion was the *result* of Martin "digging
in" and ignoring objections, not the cause of it.
>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
I don't advocate a mechanically-enforced policy, either. But it seems to
me that when a behavior is documented and has valid use cases, changing the
behavior to benefit people who *didn't* pay any attention to the
documentation or test their code for corner cases is punishing the vigilant
to aid the ignorant, and that seems unwise for us as a
community. Likewise, attempting to retroactively fix latent bugs for one
group at the cost of introducing latent bugs for another group doesn't seem
like a net improvement.
More information about the Python-Dev