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

[Phillip J. Eby]

At 01:30 PM 3/16/2007 +1300, Greg Ewing wrote:
>Mike Krell wrote:
> > I want
> > ".emacs" to be renamed to ".1.emacs", thus preserving the extensions.
> > Under the new patch, the second file would be renamed to ".emacs.1",
> > gratuitously breaking the extension preservation.
>
>This argument presupposes that ".emacs" on its own
>should be considered an extension, which is the
>very thing under dispute.

It's not under dispute for *him*, nor is it under dispute that Windows 
Explorer treats it that way.

What's *actually* under dispute here is whether it's acceptable to classify 
this perfectly useful-as-is behavior, that was documented and tested in 
released versions of Python for several years (with patches to change its 
behavior explicitly rejected in the past), as a "bug".

Unfortunately, people who are on the other side of the issue seem unable to 
conceive of the possibility that there are people who legitimately *don't* 
think this is a bug.

However, just because someone doesn't like it, doesn't make it a 
bug.  Design flaw?  Wart?  Oversight?  Perhaps.

But bug?  When it's explicitly documented and tested, and there exist 
legitimate uses of the existing behavior, even among Python-dev'ers?  Heck no.

Unfortunately, because some people have it in their heads that "'.emacs' is 
not a file extension" (to *them*), they aren't able to handle the idea that 
on Windows, it bloody well *is* a file extension, and some people would 
like to treat it as such *even on non-Windows platforms*.

They don't seem to understand that it doesn't matter how many posts they 
write "explaining" to us poor deluded souls that their interpretation of 
"extension" is the only correct interpretation, it isn't going to change 
the fact that there are *many* valid interpretations.

Reasonable people can therefore dispute what "splitext" should consider to 
be an "extension" - and it's been further pointed out that at one time, 
splitext() could and did consider '.tar.gz' to be the "extension"!

So, no matter how many times people call this a "bug", it is *not* a 
bug.  It is merely a feature that "more" people (in a straw poll of 
Python-dev) dislike than like.

However, a straw poll of Python users at large might reveal that Python's 
"explicit self" pattern is unpopular.  Should we consider that a bug, then, 
and "fix" it too, if someone offered a patch for it, because they wrote a 
program using Java-style implicit self, and it didn't work?

Yes, let's change Python so that methods and attributes don't need a self 
parameter or a "self.", and silently change the meaning of existing 
programs, because clearly anybody who *likes* explicit self is wrong and 
wrote a bad program.

So let's just "fix" their program by silently changing its meaning 
underneath them, because surely they meant 'self' to be some other function 
argument, and now anybody who writes new programs in this style will have 
them work!

(And if you think that this isn't a fair comparison, it's because you're 
not looking at it from the POV of those who like the current splitext() 
behavior.)

As Glyph says, this change is *punishing the conscientious* (i.e., everyone 
who actually read the docstrings and/or tested their code in the last 
decade and a half) to reward people who were NOT conscientious.  That seems 
backwards to me.