how to count lines in a file ?

Bengt Richter bokr at oz.net
Sat Jul 27 18:49:02 EDT 2002


On Fri, 26 Jul 2002 07:34:02 GMT, Alex Martelli <aleax at aleax.it> wrote:

>Donn Cave wrote:
>        ...
>> the garbage collection changes to the C Python that we use have not
>> compromised its reference count driven behavior at all.
>
>Not yet.  If one day a smart non-RC collector shows the potential
>for, e.g., 20% or 25% speedup, though, what then?
>
>
>> You're just looking at the other Python there, Jython.  Its object
>> lifetime policy is Java's, and that doesn't support timely finalization.
>> There's your spanner.
>
>"Timely finalization" plays very badly with efficient garbage
>collection.  You can count on a good GC system to NOT guarantee
>"timely finalization", more or less.
>
>One thought I've toyed with, at times, is to have the optional
>ability to mark a few objects as _requiring_ stricter finalization
>semantics than the run-of-the-mill kinds of objects.  E.g., files
>could be marked that way.  References to such special objects would
>then also have to be special and require the typical RC overhead
>when manipulated.  Cycles involving such objects would still be
>a bother, of course.  Alternatively, all references to such objects
>could be special kinds of weak references EXCEPT one reference
>held in the creation frame -- the object would then, differently
>from all others, be owned by one specific primary reference and
>finalized (with all other references to it, being weak, becoming
>invalid) when that one specific primary reference goes away.
>
>Semantics could be per-object rather than per-type, e.g.:
>
>        local(open('foo','w')).write('hi!\n')
>
>would not INSTANTLY close foo, but it WOULD close it as part
>of the cleanup for the current frame thanks to the hypothetical
>local() builtin.  The .write() call would in this case be
>happening on a kind of weak proxy for the file object.
>
>When I get to this point in my musings I typically tend to
>get lost wondering how to UN-localize such an object so that
>after the fact it's possible to get a more persistent reference
>to it, etc, etc.  But maybe even the simplest kind of 'local()'
>could already have some usefulness, perhaps enough to make it
>worth experimenting with.
>
I like this, but I think I would rather see timely finalization
subsumed under a general event-handling mechanism for objects. Thus
ref count going to zero would be a standard event that you could
write a handler for. A rack of event handlers might be specified
much like __slots__, except a list of tuples instead of names,
(could use a dict, but might want to specify piority order to
put likely events first) e.g., (using a fictional container for
standard platform event, perhaps extendable a la sys.modules):

class Foo:
    __events__ = [(sys.events.ON_ZERO_REFCOUNT, myFinalize)}
    ...
    def myFinalize(self, event, *rest):
       self.f.close()
    ...

Regards,
Bengt Richter



More information about the Python-list mailing list