fileinput module dangerous?

[Jorgen Grahn]

On 12 Oct 2004 21:57:40 -0700, Chris Connett <chrisconnett at gmail.com> wrote:
> I just started working with the fileinput module, and reading the bit
> about inplace modification, it seems very dangerous:
> 
> From the doc:
> ---
> Optional in-place filtering: if the keyword argument inplace=1 is
> passed to input() or to the FileInput constructor, the file is moved
> to a backup file and standard output is directed to the input file
> 
> **(if a file of the same name as the backup file already exists, it
> will be replaced silently)**.
...
> 
> This seems like very dangerous behavior, as .bak is a very common and
> useful extension for old versions of files users would like to keep
> around, and this module obliterates files one would not expect it to
> touch.  This behavior is also very un-Pythonic.

(The end user probably doesn't care if this is Pythonic or not when it
clobbers her files ...)

I had no idea it worked like this -- thanks for pointing it out!
It was such an obvious import of the Perl idiom:
    perl -pi -e 's/a/b/' file1 file2 ...
    perl -pi.bak -e 's/a/b/' file1 file2 ...
which clobbers existing .bak files -- /if you tell it to, not otherwise/.
Anything else is insane.

(Perl will happily overwrite write-protected files, at least under Unix, but
that's a different story...)

> Is there a rational reason it's this way, or should I start working on
> a patch?

I can't see how there could be a reason. I'd welcome a patch.

/Jorgen

-- 
  // Jorgen Grahn <jgrahn@       Ph'nglui mglw'nafh Cthulhu
\X/                algonet.se>   R'lyeh wgah'nagl fhtagn!