+python-ideas
---------- Forwarded message ----------
From: Kim Gräsman <kim@mvps.org>
Date: Mon, Jun 25, 2012 at 3:21 PM
Subject: Re: [Python-ideas] BackupFile
To: Masklinn <masklinn@masklinn.net>
Hi Masklinn,
Thanks for your response!
On Mon, Jun 25, 2012 at 2:33 PM, Masklinn <masklinn@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