open.read

[François Pinard]

[Alex Martelli]

> > In more recent versions of Python, the `open' built in function has been
> > replaced by the `file' built in constructor, and `open' has been made an
> > alias for `file', so the above may more adequately be written:
> >
> >     stuff = file("filename", "r").read()

> Except that, since open is an alias (and NOT deprecated), it's exactly
> equivalent (IMHO) which name you choose to use.  If open ever DOES
> get deprecated (perhaps in 3.0, some years from now) that may change.

We are not speaking of `open' deprecation.  When I write "the above may more
adequately be written", one should not read "the above must be written".

> In terms of the definition of the Python *language*, the "own destructor"
> will run whenever it pleases; thus, it's CONCEIVABLE that (in some
> perfectly valid and correct implementations of the Python language) the
> file's closing is delayed all the way to the end of the program.

Yes.  For as far as Python is concerned, this is unlikely, and much more
unlikely than conceivable.  So, in practice, there is no problem.

> you're relying on an IMPLEMENTATION detail [...]

This is related to the implementation, yes.  But this is more than a detail.
The timely finalisation is deeply built in Python, _that_ Python maintained
by Guido and team, and which most of us use and will continue to use for
years.  This implementation feature is a worth one: it allows for compact,
clear, legible and _dependable_ writings.  Moreover, this is unlikely to
change before we all die, at which point the matter is less important for
us.  I'm fully happy taking advantage of it, in the meantime.  And many do!

> Or PyPy, or some future implementation of Python for dotNET, or perhaps
> some optimizer such as psyco if it uses the semantic freedom the language
> definition so explicitly grants it to speed programs up by
> delaying/bunching up destructor-calls [...]

If this ever happens, there will be a game between developers and users,
either developers will acknowledge what users do, or they will loose some of
them.  I'm not going to live in fear of such games.  I favour legibility in
the meantime.  If I ever have, one of these days, to convert myself to the
idea of cluttering my code, I'll do.  But there is no reason to suffer now.
There is a great probability that I'll never have to undergo conversions.

> PROGRAM TO AN INTERFACE, NOT TO AN IMPLEMENTATION is a wonderful, indeed
> crucial principle.

I consider that timely finalisation in the Python we use is part of its
interface.  If undocumented, this is a politeness from Guido to Barry.

> But it breeds bad habits that may easily trip you when the time comes to
> write huge applications that will last a long time and end up using other
> implementations of the same language.

People using Jython will not preclude themselves from using Java facilities,
despite these are not available for Python, and Jython documents some of its
own features as "Python made right".  There is also a lag between Python
development and Jython development, which in general, does not get in the
way of people using features from the latest Python releases.  People using
Python on Windows allow themselves COM interfaces in their big applications.

What I mean is that, for any huge application, changing implementations,
systems, or about anything, is asking for trouble and careful revision
anyway.  People know how to make reasonable compromises between purity and
practicality, and put limits to their stumbling on the carpet flowers.
Python should be regarded as a practical language, and indeed, it is.

> Alex

You might hardly believe it, but I'm a purist and idealist as well.  Python
gives me a lot of latitude for exploring my own idealism, so I'm fulfilled
by Python in that respect.  Yet, Python is also giving me the opportunity to
relax somehow, aiming simple and legible code.  I choose to do not fear this
relaxing pleasure, even for "serious" work.  It's a nice world, isn't it?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard