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

[Huaiyu Zhu]

Delaney, Timothy <tdelaney at avaya.com> wrote:
>> From: Donn Cave [mailto:donn at drizzle.com]
>> 
>> You're describing a language other than C Python.  In C Python, you
>> *may* close files and rely on other kinds of finalizations through
>> the reference counting garbage collector, and the result is as timely
>> as if you did it explicitly.  That's finalization as it ought to be,
>> and it's a shame that other languages compromise on that.  Lots of
>> people don't think it's important, but then the majority of 
>> programmers
>> think it's OK that their programming language requires them to keep
>> track of memory in the same way.
>
>I would be very happy for this to be the case.
>
>However, CPython is not a language where you can rely on timely
>finalisation.
>
>1. The documentation explicitly states that you cannot. Anything else is an
>implementation artifact.

There is a fine difference between what you can rely on for generic Python
and what you can rely on for CPython.  Should we regard the documentation as
the most authoritative source for CPython in particular?  Obviously when it
comes the other way, no one would deny that you can rely on the existence of
certain Java classes in Jython which do not exist in Python documentation.

I've been relying on the timely garbage collection by ref-counting.  After
reading the whole thread I think I'd still trust it given what François
wrote about implicit guarantees.  These things cannot be broken in future
versions without causing a big uproar.

When porting to Jython there are other issues to consider beside open files.
They are part of the porting cost.  To guard against them all in CPython for
any program that might never be ported is likely to cost much more.

The rest of the problems you listed concern situations where ref-count does
not go down to zero, which is a different issue from the one-liners in
consideration. 

>
>2. The thing you expect to be finalised may have another reference
>somewhere. Are you 100% sure that no function you've passed it to has held a
>reference to it in a cache?
>
>3. Your object may be in a cycle. This will result in a non-timely
>finalisation.
>
>4. Your object may be in a cycle where Python explicitly punts and doesn't
>run the finalisers.
>
>Tim Delaney
>
>

Huaiyu