Should I close after popen??

[David Bolen]

pinard at iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois?= Pinard) writes:

> As it was pointed on this list quite a while ago, Python has no language
> definition per itself.  It is rather defined by the documentation of its
> main implementation.  It is true that the documentation of (C)Python does
> not commit it on the particular issue above, and this is why I checked
> with this list before starting to firmly rely on this feature, in real code.

Except that Python (the language) does have a Language Reference,
which does a reasonably good job of defining the language, sans
implementation, along with some implementation notes.  In particular,
section 3.1 talks about finalization and garbage collection as
implementation specific, and even "strongly" recommends using methods
such as close() on objects that involved external resources.

Clearly CPython has some deterministic behavior in this respect, which
has a low probability of changing at this point, and taking advantage
of that is just fine, as long as there's clarity on what the
dependence is, which is important in forum discussions such as this.

> In the meantime, I think we might continue to safely define Python as per
> (C)Python, rather than by the intersection of Jython and Python.  I do know
> that if I ever move from Python to Jython, I'll have to revise many things
> in my code, but until then, I prefer to be as clean and legible as possible.

I think "Python" should be defined as Python, and in discussions about
implementation issues, it's perfectly valid to base decisions on an
implementation such as CPython or JPython/Jython if one is willing to
have implementation-dependent code.  I guess perhaps my point was
somewhat pedantic, but in a discussion about implementation dependent
items, I think it's best to be clear on naming the implementations.

> The close *is* properly done.  This is guaranteed by the fact I do not
> keep any reference to the file.  On the first example, the close is done
> before proceeding with the next Python instruction.  On the second example,
> the close is done even before the first "process(line)" is executed.

In current CPython yes, but not guaranteed by Python the language (per
the reference which is very clear on that fact).

> About errors, shouldn't we just rely on the fact that they raise exceptions,
> automatically?  One of the beauties of Python, compared to C or Perl, is that
> errors are always trapped and handled by the system, when not by the user.

Except that if the finalization was postponed, that exception might
crop up in the strangest place (assuming it was propagated up at all).

But aren't exceptions that occur as part of finalization suppressed?
Assuming that the internal file type works similarly to Python code
objects, where exceptions are definitely suppressed in __del__
processing (see language reference section 3.3.1, under the Warning:
note for __del__).

> So, we have all guarantees that the data got written to the logfile, given
> the script does not fail with an I/O error.  Errors on implicit close will
> also be properly detected.  So, there is no need to feel uncomfortable! :-)

Just as an FYI, but that's not true in CPython.  The close that is
done during object deallocation ignores any error codes, unlike that
done in response to a close() method call.  This is true in at least
1.5.2 and 2.x which I had source around for.  So errors on implicit
closes will be silently ignored.

Note that I'm definitely not trying to force a certain comfort level
on yourself - you have the right to feel as comfortable or
uncomfortable depending on implementation-specific behavior as you
like :-)

But at the same time, I think it's worth pointing out the risks in
such dependence (note your assumption about exceptions), since it's up
to each developer to make that risk/ease tradeoff.

For me, while I may make the trade-off with read-only operations, I
don't think I'd do it if I were writing.  And even for reading, for
best use of resources in the most portable way, explicit close() is
better.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/