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

["Martin v. Löwis"]

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