[Python-Dev] Proposal to revert r54204 (splitext change)
fuzzyman at voidspace.org.uk
Wed Mar 14 22:45:15 CET 2007
Phillip J. Eby wrote:
> At 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote:
>> Phillip J. Eby wrote:
>>> In addition to being made in the face of controversy and opposition,
>>> change is an alteration to *documented and tested* behavior and thus
>>> cannot reasonably be considered a mere bug fix.
>> FWIW, I support Phillip on this. There can be no question that the old
>> behaviour was expected.
>> IMO this is just gratuitous breakage. The only fix that shold be made is
>> to the splitext documentation to match the docstring.
>> A change to the documented behaviour should require a __future__ import
>> for at least one version. That's even assuming that the change is
>> desireable (I don't believe so). We have multiple anecdotes of actual,
>> existing code that *will* break with this change. So far I haven't seen
>> any actual code posted that is currently broken by the existing behaviour.
> FWIW, I think that, were we writing splitext() *now*, we should go with the
> proposed behavior. It's reasonable and justifiable even on Windows (even
> though Windows Explorer agrees with the current splitext() behavior.)
> But, that doesn't actually have any bearing on the current discussion,
> since splitext()'s behavior is existing and documented.
> Certainly, there *is* code that's broken by the existing behavior --
> otherwise the patch would never have been submitted in the first
> place. However, that doesn't automatically make it a Python bug,
> especially if the existing behavior is documented and covered by regression
> I just want to clarify this point, because I don't wish to enter another
> round of discussion about the merits of one behavior or the other: the
> merits one way or the other are pretty much irrelevant to the policy issue
> at hand.
It looks to me like a clear bugfix (the fact that there were unit tests
for the insane behaviour doesn't make it any less a bug). The current
docstring that states that the first element may be empty hardly counts
as it being a 'documented feature'.
At the least it is a grey area and not a policy reversal. The policy is
that bugfixes can go in with warnings. So, as a debatable issue whether
it is a bug (I think it is fairly clear), then it doesn't change or
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
More information about the Python-Dev