[Python-ideas] BackupFile

[Kim Gräsman]

+python-ideas


---------- Forwarded message ----------
From: Kim Gräsman <kim at mvps.org>
Date: Mon, Jun 25, 2012 at 3:21 PM
Subject: Re: [Python-ideas] BackupFile
To: Masklinn <masklinn at masklinn.net>

Hi Masklinn,

Thanks for your response!

On Mon, Jun 25, 2012 at 2:33 PM, Masklinn <masklinn at masklinn.net> wrote:
> On 2012-06-25, at 14:17 , Kim Gräsman wrote:
>>
>> - Would something like this be useful outside of my office?
>
> I'm not sure I correctly understand the purpose of this, and if I do it
> seems to be kind-of a hack for "fixing" kind-of crummy code: is it
> correct that the goal is to temporarily edit a file (and restore it
> later) to change the behavior of *other* pieces of code reading the same
> file?
>
> So essentially dynamically scoping the content of a file?

Yes, that's it. I use it to adapt the behavior of third-party code I
can only affect through configuration files.

> I find the idea rather troublesome/problematic, as it's completely
> blind to (and unsafe under) concurrent access, and will be tricky to
> handle cleanly wrt filesystem caches and commits.

Good point. I use this in a controlled environment, where I know
nobody else is using the file. Multiple concurrent users would break
this completely...

> The initial mail hinted at atomic file replacement *or* backuping a file
> and restoring the backup on error, something along the lines of:
>
>    with Backup(settings_file):
>        alter_file()
>        alter_file_2()
>        alter_file_3()
>    # altered file

Nope, not this.

>    with Backup(settings_file):
>        alter_file()
>        alter_file_2()
>        raise Exception("boom")
>        alter_file_3()
>    # old file is back

This is what I was aiming for, except old file would be
unconditionally restored.

> in the same way e.g. Emacs will keep "~" files around during edition. That
> could have been a ~+1 for me, but the behavior as I understood it
> (understanding which may be incorrect, again) I'd be -1 on, it seems too
> dangerous and too tied to other issues in the code.

Yeah, I think the concurrency aspect of it makes it easy to misuse, so
it's probably not a good fit for the standard library.

- Kim