[Python-Dev] splitext('.cshrc')

["Martin v. Löwis"]

Andrew Bennetts schrieb:
> Glyph's proposing that rather than risk breaking existing code (and in the worst
> possible way: silently, giving wrong answers rather than exceptions), we examine
> what benefits changing splitext would bring, and see if there's a way to get
> those benefits without that risk.  I don't think that's an idea to dismiss out
> of hand.

But I did list what I consider the benefits of the change to be, in

http://mail.python.org/pipermail/python-dev/2007-March/071675.html

(the message you are responding to).

I don't see any other way of achieving these benefits without changing
splitext, so I didn't propose any alternatives. I haven't seen any other
proposal, either.

> At the moment you seem to be saying that because you're possibly fixing some
> currently buggy code, it's ok to possibly break some currently working code.
> I'm not sure that's a good idea, and I expect it will create headaches for
> someone trying to be compatible with both 2.5 and 2.6.

I personally don't expect severe or massive breakage. It's a small
detail.

> If the existing behaviour was clearly buggy by the existing documentation,
> rather than undefined, this would be less of a concern.
> 
> The point about silent failures is an important one too.

I see all these objections. I just don't see them outweigh the advantages.

> If "splitext" was removed and replaced with, say, a "split_ext" that behaves as
> you (and basically everyone, myself included) agrees it should behave, then code
> won't silently do the wrong thing.  It will immediately and visibly fail, in an
> understandable way.  Similarly, if split_ext was added side-by-side with
> splitext, and splitext changed to emit DeprecationWarnings for a release,
> there's minimal risk that existing code that works would break.

I considered these alternatives, and rejected them. Outright removing 
splitext would break a lot of code, period. I can't see how this could
possibly be better than the currently implemented change.

Raising a DeprecationWarning would also break a lot code, although in
a less aggressive way. Who is going to see these warnings? The end
users, running Python applications and using libraries they have not
written. Fixing them will involve a very large cost in the community
(spread over many people). Raising a DeprecationWarning should not be
taken lightly.

OTOH, silently changing the current behavior might break some 
applications. Again, it is the users who will notice, but for this
change, it will be less users, as I expect that breakage will be
really uncommon.

> I wonder if "First, do no harm" should be an explicit guideline when it comes
> evaluating incompatible changes, even if they fix other things?

If possible, sure. However, I don't see how this is possible here. All
your proposed alternatives do more harm than the one implemented.

> All that said, I don't think I've ever used splitext myself, so I don't care so
> much about what happens to it.  But I do worry about the general approach to
> backwards compatibility.

It's not a general approach. It's a case-by-case decision. Please 
understand that *any* change is "incompatible", in the sense that
I can come up with an application that breaks under the change.
Really. *ANY CHANGE*. So the only way to get 100% compatibility
is to not change anything at all.

Regards,
Martin