[Python-Dev] __del__ and tp_dealloc in the IO lib

[Giovanni Bajo]

On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
> On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo <rasky at develer.com> wrote:
> > CPython will always use reference counting and thus have a simple and
> > clear GC criteria that can be exploited to simplify the code.
> 
> Believe this at your own peril.
> 
> Once, CPython didn't have GC at all (apart from refcounting). Now it
> does. There are GC techniques that delay DECREF operations until it's
> more convenient. If someone finds a way to exploit that technique to
> save 10% of execution time it would only be right to start using it.
> 
> You *can* assume that objects that are no longer referenced will
> *eventually* be GC'ed, and that GC'ing a file means flushing its
> buffer and closing its file descriptor. You *cannot* assume that
> objects are *immediately* GC'ed. This is already not always true in
> CPython for many different reasons, like objects involved in cycles,
> weak references,

I don't understand what you mean with weak references delaying object
deallocation. I'm probably missing something here...

>  or tracebacks saved with exceptions, or perhaps
> profiling/debugging hooks. If we found a good reason to introduce file
> objects into some kind of cycle or weak reference dict, I could see
> file objects getting delayed reclamation even without changes in GC
> implementation.

That would be break so much code that I doubt that, in practice, you can
slip it through within a release. Besides, being able to write simpler
code like "for L in open("foo.txt")" is per-se a good reason *not to*
put file objects in cycles; so you will probably need more than one good
reason to change this. OK, not *you* because of your BDFL powers ;), but
anyone else would surely have to face great opposition.

The fact that file objects are collected and closed immediately in all
reasonable use cases (and even in case of exceptions, that you mention,
things get even better with the new semantic of the except clause) is a
*good* property of Python. I regularly see people *happy* about it.

I miss to understand why many Python developers are so fierce in trying
to push the idea of cross-python compatibility (which is something that
does simply *not* exist in real world for applications) or to warn about
rainy days in the future when this would stop working in CPython. I
would strongly prefer that CPython would settle on (= document) using
reference counting and immediate destruction so that people can stop
making their everyday code more complex with no benefit. You will be
losing no more than an open door that nobody has entered in 20 years,
and people would only benefit from it.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com