how to count lines in a file ?

[Michael Gilfix]

  Ok. That cleared it up. Thanks. I can't say that I've used the
__del__ method in a long time but I do remember that when I had used
it, I expected that python would always invoke it at some point, even
at shutdown of the interpreter. It seems the only really useful thing
for __del__ is if someone wants to explciitly 'del object' instead of
something like 'object.shutdown()'. But I'm sure you can give me a
better use case at any rate. But for the most part, gc semantics mean
that __del__ loses its usefulness.

                    -- Mike

On Fri, Jul 26 @ 13:06, Delaney, Timothy wrote:
> Do you gain anything? Decreased performance perhaps. Some flexibility if you
> want to intercept some method calls, etc. For the stated purpose though, no.
> 
> Refcount system:
> 
> Proxy object is created and assigned to a name
>     proxy refcount incremented
> File object is assigned to field of proxy object
>     file refcount incremented
> Proxy deleted
>     proxy refcount decremented
>     proxy collected
>     file refcount decremented
>     file collected (and closed)
> 
> Non-refcount system:
> 
> Proxy object is created and assigned to a name
>     proxy is referenced
> File object is assigned to field of proxy object
>     file is referenced
> Proxy is deleted
>     proxy not referenced - candidate for collection
> Time passes
> Proxy is collected
>     file is not referenced - candidate for collection
> Time passes
> File is collected
> 
> In a refcount system (with no cycles), you have a reasonable guarantee that
> all the garbage will be collected (there are cases where it will not happen,
> but they are all due to abnormal termination).
> 
> In a non-refcount system, garbage will hang around for an indeterminate
> period of time. If your program finishes before that garbage is collected,
> it may never be collected (and any code in the finaliser will not be run).
> 
> CPython uses refcounts for everything, but if an object is involved in a
> cycle there is an indeterminate period of time before cycles are broken,
> meaning that they will not be collected when the last non-cyclic reference
> is removed.
> 
> This did not affect files, because files could not become involved in
> cycles. There was a proposal which would have involved every file being in a
> cycle. Files would then have not gone away when people expected (luckily for
> people with such broken code, the devs care about them).
> 
> In Jython (and JPython) it has always been the case that you can't rely on
> things going away immediately, since they use Java garbage collection. Now
> it's starting to become an issue in CPython. The only reason it *is* an
> issue in CPython is because many people don't clean up the resources they
> use when they're finished with them, counter to the strong recommendation in
> the Python documentation.
> 
> Tim Delaney
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
`-> (tdelaney)

-- 
Michael Gilfix
mgilfix at eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html