<br><br><div><span class="gmail_quote">On 3/14/07, <b class="gmail_sendername">"Martin v. Löwis"</b> <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thomas Wouters schrieb:<br>> However, changing documented, tested behaviour without warning gives<br>> Python an even worse name. I agree with PJE that the change is the wrong<br>> thing to do, simply because it sets (yet another) precedent. If
<br>> providing an alternate API with clearer semantics is too 'heavy-weight'<br>> a solution and warning is for some reason unacceptable (I don't see why;<br>> all the arguments against warning there go for *any* warning in Python)
<br>> -- then the problem isn't bad enough to fix it by breaking other code.<br><br>I think producing pointless warnings also gives Python a bad name<br>(I've seen many complaints about Python's warnings in the past, in
<br> particular when they fill up Apache log files).</blockquote><div><br>I would be more pissed if my apache logfiles were full of errors, instead :-) But perhaps we should be more forward about the use of warnings: warn people (so to speak) about warnings, and tell them about the -W option for making them louder/quieter.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">However, if everybody (and here I mean everybody) can agree that adding<br>a warning to the current implementation would be an acceptable
<br>compromise, I could agree to such a compromise also (although I<br>would prefer if somebody else took the blame for adding that warning.<br>I happily take the blame for changing the behavior).<br><br>What specific warning would you propose, and in what specific
<br>circumstance would it be issued?</blockquote><div><br>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. We do this for three reasons:
<br><br> - 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.
<br></div><br> - 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. Furthermore, even if the original programmer is a user of his or her own program and uses Python
2.6, he or she may never trigger the erroneous behaviour himself. The user who got the warning is the only one who can tell him or her that there's a problem with dotfiles. (Even though only a small fraction of the actual users will send in a bug -- it's still the best we can do.)
<br><br> - Most importantly, people who don't care about the change, whose code works acceptibly with either version of os.path.splitext, will get warned about the change in behaviour. If, as in one of the given examples in this thread, files are renamed based on their 'extension', it may work either way, and it may make sense either way, but it will *change*. Files may end up being differently renamed. I don't see that as acceptible behaviour, for upgrading python to cause a subtle but noticeable change in how a program does its work -- without error. That's why we warn.
<br><br>There is a big difference between fixing this, and fixing bugs that are obviously bugs: functions that behave differently from the documentation or (if not documented) in obviously wrong ways. If you need to wonder what 'obvious' means: if the "average programmer" using the function does not realize he's getting 'incorrect' behaviour, it's not obviously wrong. This entire thread should make it obvious that
os.path.splitext's old behaviour, while nonsensical if you think about it, is not *obviously* wrong. If os.path.splitext(".dotfile") were to return (".dotfile", ".dotfile"), that would be obviously wrong. What it does now is not. Changing it is the right thing, but changing it without first warning about it is not.
<br></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!