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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com