Closing of FileType-type arguments
Ted Tibbetts
This may be a bit nit-picky, but I'm wondering if there are any
precautions taken against leaving FileType-type arguments unclosed.
So for example, if I do ::
parser.add_argument('file', type=FileType('w'))
parser.add_argument('number', type=int)
and call it with
$ python script.py some_file not-an-integer
does the file 'some_file' get closed after having been open for
writing?
Having dipped my foot in the source briefly it doesn't seem like
there's any code to close an open file-type argument in the case where
another argument's invalidity raises ArgumentError all the way up to
whatever called `parser.parse_args`. Since the namespace doesn't end
up getting returned, the caller can't close the files, because it has
no way to find them.
Is this just not something to be concerned with, assuming that the app
is going to exit right away anyway? Or should this be considered a
bug? I didn't see anything on the bug tracker, and it doesn't look
like anything related has been changed on `trunk`_ since version 1.1.
.. _trunk: http://svn.python.org/view/python/trunk/Lib/argparse.py?view=log
It would also be neat if the returned namespace was a context manager
to facilitate closing FileTypes and other context-y elements in code
that uses the namespace. Like maybe a `argparse.ClosesWithNamespace`
argument-type class that registers that wraps its argument with code
to register it as something that the namespace context needs to
close. So that you could do something like
with parser.parse_args() as ns:
if not good(ns):
raise HellError
Steven Bethard
<cecinemap...@gmail.com> wrote:
> This may be a bit nit-picky, but I'm wondering if there are any
> precautions taken against leaving FileType-type arguments unclosed.
> So for example, if I do ::
>
> parser.add_argument('file', type=FileType('w'))
> parser.add_argument('number', type=int)
>
> and call it with
>
> $ python script.py some_file not-an-integer
>
> does the file 'some_file' get closed after having been open for
> writing?
Well, it gets closed, but only because CPython will call the close
when the file gets garbage collected before Python shuts down.
> Having dipped my foot in the source briefly it doesn't seem like
> there's any code to close an open file-type argument in the case where
> another argument's invalidity raises ArgumentError all the way up to
> whatever called `parser.parse_args`. Since the namespace doesn't end
> up getting returned, the caller can't close the files, because it has
> no way to find them.
Yeah, that's correct.
> Is this just not something to be concerned with, assuming that the app
> is going to exit right away anyway?
For 99.9% of applications, this isn't something you should worry
about. That other 0.1% is overriding the exit method, and I guess
something like this could perhaps bother them.
> Or should this be considered a
> bug? I didn't see anything on the bug tracker
Argparse bugs are now on the main Python tracker, bugs.python.org. But
I don't believe there's anything like this up there now.
> It would also be neat if the returned namespace was a context manager
> to facilitate closing FileTypes and other context-y elements in code
> that uses the namespace. Like maybe a `argparse.ClosesWithNamespace`
> argument-type class that registers that wraps its argument with code
> to register it as something that the namespace context needs to
> close. So that you could do something like
>
> with parser.parse_args() as ns:
> if not good(ns):
> raise HellError
I'm happy to review patches that do something like this, but this
might be a little tricky to implement without breaking backwards
compatibility (e.g. if the user passes in a namespace, then you can't
wrap it in a context manager because they're expecting to get that
same namespace back).
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus