[Python-ideas] BackupFile (original) (raw)

Kim Gräsman kim at mvps.org
Mon Jun 25 16:39:33 CEST 2012


+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(settingsfile):  alterfile()  alterfile2()  alterfile3()  # altered file

Nope, not this.

 with Backup(settingsfile):  alterfile()  alterfile2()  raise Exception("boom")  alterfile3()  # 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.



More information about the Python-ideas mailing list