[Python-Dev] Proposal to revert r54204 (splitext change)
mbk.lists at gmail.com
Thu Mar 15 22:56:52 CET 2007
On 3/15/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Mike Krell schrieb:
> > Sure:
> > for f in files:
> > try:
> > (root, ext) = os.path.splitext(f)
> > os.rename(f, '%s.%s%s' % (root, index, ext))
> > except OSError:
> > die('renaming %s failed' % f)
> Thanks! Looking more closely, it's not entirely clear where index
> comes from - what if you already have "a.1.txt". Will you set it
> to 2? Will that then produce a.1.2.txt?
A bit more background: This runs periodically in a setting where the
files in the file list are regenerated in between invocations of this
code. Each time a renaming occurs, the index is incremented (it is
preserved in a file in between invocations). Thus, various
incarnations of "a.txt" would be archived as "a.1.txt", "a.2.txt",
etc. Similarly, copies of ".emacs" would be made as ".1.emacs",
".2.emacs", etc. If "b.1.txt" appeared in the list of files to be
archived, it would be archived as "b.1.1.txt", "b.1.2.txt", etc.
> > Under the new patch, [.emacs] would be renamed to ".emacs.1",
> > gratuitously breaking the extension preservation.
> I can see that it breaks the behavior you intended it to have. However,
> I disagree that it broke "extension preservation". Rather, it *provides*
> extension preservation, something that the old code did not do.
Here is a point of confusion. Bear in mind I'm running this under
windows, so explorer happily reports that ".emacs" has a type of
"emacs". (In windows, file types are registered in the system based
on the extension -- all the characters following the last dot. An
unregistered extension is listed as its own type. Thus files ending
in .txt are listed as type "Text Document", but files ending in
".emacs" are listed as type "emacs" because it's an unregistered
I often sort files in the explorer based on type, and I want a file
and all its backups to appear next to each other in such a sorted
list. That's exactly why I rename the files the way I do.
Thus, ".1.emacs" is what I want, and ".emacs.1" is a markedly inferior
and unacceptable alternative. That's what I'm referring to by
> I also like to point out that the primary objective of the code
> ("archive arbitrary files") is still preserved - it still does that,
> but in different manner. (disclaimer: I don't fully understand the
> index part)
BTW, I want to echo Brett Cannon's comments about the tone. I've been
a bit testy about this breakage, however, upon reflection, it's clear
that it's not Martin's fault, but rather a shortcoming of the process.
Sorry, Martin. If you or anyone else was offended, please accept my
More information about the Python-Dev