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

"Martin v. Löwis" martin at v.loewis.de
Fri Mar 16 13:51:24 CET 2007

Thomas Wouters schrieb:

Hah, everyone agree? They weren't agreeing when you changed it, either :) But no, we don't add a warning and change the API. We add a warning about changing the API. 2.6 sees no semantic change, just a warning when os.path.splitext is used on a dotfile with no extension (or a file with an extension but no name, so you will.) 2.7/3.0 see the change in semantics.

Would you like to work on that? Feel free to undo my changes as needed, although I think the merging of the various implementations of splitext can be kept, as should the additional test cases (just with a different outcome). The tracker reports need to be updated to indicate the change, too.

- People who rely on the documented, tested, ages-old behaviour will get fair warning that the behaviour will change. I don't mean just programmers. I mean users, too. Yes, users will get to see the warning and many of them might not be able to do something about it. Well, considering this class of users would get a behavioural change, and quite likely a bug, giving them a warning hardly seems intrusive.

Here I disagree. I believe many people will see the warning that won't see any behavior change (except for temporarily getting a warning). Much code will do

for fn in os.listdir(path): if os.path.splitext(fn)[1] in ('.c', '.h', '.vcproj'): some_action

This code will be unaffected by the change, unless people have a file called .c in a directory.

- People who (inadvertently) rely on the new behaviour get a warning that their code is currently bugged. This includes users, too, of course: they get a warning that this program is bugged in older versions of Python. If there was a way to telepathically warn the actual programmer, that would be better, but there isn't, so we can't. We will have to use the user as the messenger.

But we do warn the programmer: there is a change in the documentation (not just Misc/NEWS).

What it does now is not. Changing it is the right thing, but changing it without first warning about it is not.

Ok, I can accept a solution that will allow it to be changed eventually, although I'm not happy with producing a warning. So, as I said, if somebody wants to commit such a change, go ahead. If you want me to review it first, I can do that as well.

Regards, Martin

More information about the Python-Dev mailing list