[Python-Dev] Proposal to revert r54204 (splitext change)
"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
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,
> - 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) in ('.c', '.h', '.vcproj'):
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.
More information about the Python-Dev