Issue #222: Re-opening NamedTemporaryFile is not valid on Windows (blais/beancount)
12 views
Skip to first unread message
Jeff Brantley
Feb 26, 2018, 12:56:00 AM2/26/18
to bean...@googlegroups.com
New issue 222: Re-opening NamedTemporaryFile is not valid on Windows
https://bitbucket.org/blais/beancount/issues/222/re-opening-namedtemporaryfile-is-not-valid
Jeff Brantley:
Both test and production code are using `tempfile.NamedTemporaryFile`, which on non-Windows can be re-opened (by name) while the original handle is still open. For example, `beancount.utils.test_utils.docfile` decorator extracts a test's docstring, writes it to a file, and then---still holding the file open---passes the filename to the test, to be read by that test.
Searching the repo for NamedTemporaryFile turns up 10 files with "test" in the name, as well as `beancount.parser.lexer` and `beancount.utils.text_utils`.
It's unfortunate that this doesn't just work. Assuming all instances are in a `with` statement (not true, but perhaps that is a bug?), then it may be possible to workaround with a wrapper that passes `delete=False` and then manually deletes the file on `__exit__`. I'm not sure what flaws (if any) this may exhibit over the real thing.
https://bitbucket.org/blais/beancount/issues/222/re-opening-namedtemporaryfile-is-not-valid
Jeff Brantley:
Both test and production code are using `tempfile.NamedTemporaryFile`, which on non-Windows can be re-opened (by name) while the original handle is still open. For example, `beancount.utils.test_utils.docfile` decorator extracts a test's docstring, writes it to a file, and then---still holding the file open---passes the filename to the test, to be read by that test.
Searching the repo for NamedTemporaryFile turns up 10 files with "test" in the name, as well as `beancount.parser.lexer` and `beancount.utils.text_utils`.
It's unfortunate that this doesn't just work. Assuming all instances are in a `with` statement (not true, but perhaps that is a bug?), then it may be possible to workaround with a wrapper that passes `delete=False` and then manually deletes the file on `__exit__`. I'm not sure what flaws (if any) this may exhibit over the real thing.
Reply all
Reply to author
Forward
0 new messages