automatic reclaiminig of limited resources (was Re: [Python-Dev] Product iteration)

[Peter Funk]

Hi,

Tim Peters:
> > [about Class().method()-idiom] 
[...]
> You don't have to dig that deep:  they're also common in the standard
> distribution, including at least two of mine (checkappend.py and
> tabnanny.py).  There's a long copy/paste/modify tradition of not bothering
> to close file objects in multi-file tools, dating back at least to Guido's
> 1991 eptags.py <wink>.
> 
> These aren't hard to "fix", but that isn't the point.  A lot of code out
> there would start failing in data- and platform-dependent ways if CPython
> stopped cleaning up dead file objects "real soon" after they die, and
> there's no easy way to identify in advance which code that may be.  It would
> piss off a lot of people!

Thank you!  Pheew.  

This applies in particular not only to file descriptors.
This hits other limited resources also: color table entries, windows,
network connections and so on.  

> But I don't know why we're arguing about it.  Nobody (AFAIK) has announced
> plans to take refcounting out of CPython, but that you can't *rely* on
> refcounting across Python implementations is ancient news (and a reality in
> practice since JPython).

This topic was initially raised in the recent discussion about weak
references which had a completely different subject line: "Product
iteration".  

Mark Hammond wrote in this thread:
MH> I have no problem with this at all.  The sooner we point out the broken
MH> code the better.  The last thing we want is for obviously and documented
MH> broken code to suddenly be considered non-broken simply by the volume of
MH> poor code out there...

Here I would say : "too late!"  The volume of code is already there
and from my POV this code simply doesn't look broken.  I think it is
but elegant, because it is usually shorter and was easier to write,
because the programmer hasn't to bother too much about any external
resources, which may have been used by some temp objects under the hood.

> Guido certainly can't *require* that all implementations use refcounting!

Okay.  But this is "(for language lawyers)" anyway ;-).  Anybody who
want's to develop a seriously competing Python implementation is well
advised to implement a similar "real soon" object recycling strategy
regardless of what the Language Reference may tell them and what Guido
"require".  The existing code requires it.

The current reliable automatic recycling behaviour in C-Python is
so very very convenient, that I wouldn't want to do without it in
practice.  This is like having to use the staircase to go upstairs
to the 10th floor in a building if there is an elevator with an open
door just beside the first step.

> The Reference Manual has been clear about this for years, and other
> implementations already rely on what they were promised there:  it's already
> too late to stop this from being a basis on which implementations will
> compete.

Competing Python implementations?  Hmmm....  Hmmm.... there is 
"stackless" but AFAIK it also uses refcounting... <duck>. ;-)

Happy with C-Python, Peter