[Python-Dev] Proposal to revert r54204 (splitext change)
Phillip J. Eby
pje at telecommunity.com
Fri Mar 16 02:32:19 CET 2007
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
(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()
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.
More information about the Python-Dev