Why no open(f, "w").write()?

[Gary Herron]

On Wednesday 29 May 2002 03:30 pm, François Pinard wrote:
> [Gary Herron]
>
> > Thus the "bad" part of this programming practice is that the timing
> > of the implied close is dependent Python implementation issues (i.e.,
> > the timing of the garbage collection), and such dependencies are never
> > a good thing to rely on.
>
> There might be cases when one moves between Python and Jython, indeed.
> When one knows s/he works with Python only, it is good style to rely on
> the refcount behaviour, as it yields code which is not only more legible,
> but also more elegant and concise.  It means that you understand and
> accept in advance having to revise your code if you ever want to use other
> implementations of Python, like Jython.  As someone was pointing to me
> very recently, the Python reference tries to describe a common language,
> but there is no "C-Python" specific guide.  If there was one, the refcount
> behaviour would most probably be described as dependable and reliable,
> even through future versions, as far as Python programming is concerned.
>
> And besides, it seems that the few implementations of Python do not support
> exactly the same language: extensions here may not be available there.
> Defining "good style" as the common subset of all Python implementations,
> and everything else as "bad style", seems questionable.  The only thing
> is that you have to be aware of the implications of your choices.
>
> For this "Jython-forces-you-to-explicit-closes" matter, my feeling is that
> Jython encourages bad style here, much more than it defines good style.
> Surely, there has never been a bad intent from Jython author.  We
> understand that the limitation comes from the fact Jython relies on the
> Java system for collecting garbage.  One has to close explicitly in Jython
> for practical implementation considerations, this has nothing to do with
> good style.

Lots of what you say is true, but not applicable in this case.  The example
  
  open(f, 'w').write(stuff)

depends on an accident of current versions of this implementation of
Python.  The manual is quite explicit about NOT being able to depend
ANY particualar "features" of garbage collection -- not even on its
existence.

I think we can agree that it must be considered "bad prgramming
practice" to depend on features which the manual claims may not exist,
past, present, or future.


Here's the quote from the Reference Manual:

  Objects are never explicitly destroyed; however, when they become
  unreachable they may be garbage-collected. An implementation is
  allowed to postpone garbage collection or omit it altogether -- it
  is a matter of implementation quality how garbage collection is
  implemented, as long as no objects are collected that are still
  reachable. (Implementation note: the current implementation uses a
  reference-counting scheme with (optional) delayed detection of
  cyclicly linked garbage, which collects most objects as soon as they
  become unreachable, but is not guaranteed to collect garbage
  containing circular references. See the Python Library Reference for
  information on controlling the collection of cyclic garbage.)

Gary Herron