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

[Thomas Wouters]

On 3/14/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>
> Thomas Wouters schrieb:
> > However, changing documented, tested behaviour without warning gives
> > Python an even worse name. I agree with PJE that the change is the wrong
> > thing to do, simply because it sets (yet another) precedent. If
> > providing an alternate API with clearer semantics is too 'heavy-weight'
> > a solution and warning is for some reason unacceptable (I don't see why;
> > all the arguments against warning there go for *any* warning in Python)
> > -- then the problem isn't bad enough to fix it by breaking other code.
>
> I think producing pointless warnings also gives Python a bad name
> (I've seen many complaints about Python's warnings in the past, in
>   particular when they fill up Apache log files).


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.

However, if everybody (and here I mean everybody) can agree that adding
> a warning to the current implementation would be an acceptable
> compromise, I could agree to such a compromise also (although I
> would prefer if somebody else took the blame for adding that warning.
> I happily take the blame for changing the behavior).
>
> What specific warning would you propose, and in what specific
> circumstance would it be issued?


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:

 - 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.

 - 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.)

 - 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.

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.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070316/9711676e/attachment.htm