<html><body><br />On 8 Mar, 06:02 pm, phd@phd.pp.ru wrote:<br />>On Thu, Mar 08, 2007 at 06:54:30PM +0100, "Martin v. L?wis" wrote:<br />>>      back_name = splitext(name[0]) + '.bak'<br />><br />>back_name = splitext(name)[0] + '.bak'<br /><br />This is really totally secondary to the point I actually care about, but seeing this antipattern bandied about as a reason to make the change is starting to bother me.<br /><br />There's no way to "fix" this idiom.  Forget the corner case; what if you have a foobar.py and a foobar.txt in the same directory?  This is not at all uncommon, and your "backup" function here will clobber those files in any case.<br /><br />Furthermore, although the module documentation is vague, the docstring for splitext specifically says "either part may be empty" and "extension is everything from the last dot to the end".  Again, this is a case of needing a function designed to perform a specific task, and instead relying on half-broken idioms which involve other functions.  make_backup_filename(x) might *use* splitext, but it is not what splitext is *for*.  A correct implementation which did use splitext would look like this:<br /><br />    def make_backup_filename(filename):<br />        base, extension = splitext(filename)<br />        return base + '.bak' + extension<br /><br />although personally I would probably prefer this:<br /><br />    def make_backup_filename(filename):<br />        return filename + '.bak'<br /><br />If the behavior of the old code is going to be buggy in any case, it might as well be buggy and consistent.  Consider a program that periodically makes and then cleans up backup files, and uses the "correct" splitext-using function above.  Perhaps .cshrc.bak makes more sense than .bak.cshrc to some people, but that means that on a system where python is upgraded, .bak.cshrc will be left around forever.  Even on a program whose functionality is improved by this change, the incompatibility between versions might create problems.<br /></body></html>