how to count lines in a file ?

[Andreas Kostyrka]

Am Sam, 2002-07-27 um 05.44 schrieb Steve Holden:
 So, what you *seem* to be saying is that it would be p[erfectly possible to
> collect objects thatdon't have __del__() methods, but once they acquire such
> they are no longer collectible even when only cyclic references exist? That
> seems an odd asserion.
Nope.

Consider:
class A:
	def close(self):
		self.child.close()
	def __del__(self):
		self.close()

a=A()
b=A()
a.child=b
b.child=a

Now we have a basic cyclic reference. Please explain to me, if a or b
should be deleted first?

Basically, if you do have __del__ methods, these might try to do
something with the __dict__ values or slots. Now, without __del__, this
works quite well, because we just free the memory, and that was it.

> Well, certainly you *always* have to be careful that references haven't been
> invalidated before use.
But thats the problem. Python being dynamic, you cannot even try to sort
the deletion because we cannot be sure about what __del__ does before we
try to execute it. (eval&exec are our friends[enemies] here)

And there cases that are unsolvable (because a depends upon b for
deletion and vica-versa).

So Python doesn't try. 
> 
> > It's a sort of philosophical thing. If you can be sure that having closed
> > the door, no-one will open it again then the room on the other side is
> > allowed to simply disappear ;-)
> >
> > __del__ only has sensible semantics in the presence of reference counting.
> > Either have reference counting or throw away __del__. When it comes down
> to
> > it you gotta pick one or the other.
> >
> I'm afraid you're going to have to explain that one. I don't think there is
> any great philosophical difference bvetween ourpositions, but I'm not yuet
Well, it's actually trivial. The execution environment of finalization
in "true" garbage collection are usually to random to be of any use,
except perhaps unconditional release of external resources (but this
doesn't happen usually at the Python level, this is more a thing for C
language level interface modules).

This is so, because no GC algorithm (except reference counting) gives 
you any order of deallocation. (basically they are random)
Consider an object a that is registered with another one [m].

Now one might propose that a deregisters from m in it's finalization.
But with true garbage collection a cannot be sure, that m still exists. 

Basically, because the system state during collection is in a flux, the
possible failure modes for finalization functions multiple quite fast.

Now there uses for finalization with GC, but they usually do not apply
to python (because python do not contain things like unprotected
references, etc., and the whole interfacing with non-gc libraries is
done in C).  
> completely sure I understand what you are saying. As the Reverend Sydney
> Smith observed upon seeing two women shouting at each other from opposite
> windows: "I fear they will never agree, for they are arguing from different
> premises".

Andreas