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

"Martin v. Löwis" martin at v.loewis.de
Thu Mar 8 10:37:32 CET 2007

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

More information about the Python-Dev mailing list