Question About When Objects Are Destroyed (continued)

[Tim Daneliuk]

On 08/05/2017 03:21 PM, Chris Angelico wrote:
> After a 'with' block,
> the object *still exists*, but it has been "exited" in some way
> (usually by closing/releasing an underlying resource).

The containing object exists, but the things that the closing
logic explicitly released do not.  In some sense, a context
acts like a deconstructor, just not on the object it's associated
with.


> If there's a resource you need to clean up, you clean that up
> explicitly,

Such "resources" *are* objects themselves notionally.  You are exactly
killing those objects to free the underlying resources they consume.

> so the object's lifetime shouldn't matter to you.

I disagree with this most strongly.  That's only true when the machine
resources being consumed by your Python object are small in size.  But
when you're dynamically cranking out millions of objects of relatively
short lifetime, you can easily bump into the real world limits of
practical machinery.  "Wait until the reference count sweep gets rid of
it" only works when you have plenty of room to squander.

Also, waiting for the reference count/gc to do its thing is
nondeterministic in time.  It's going to happen sooner or later, but not
at the same or a predictable interval.  If you want to write large,
performant code, you don't want this kind of variability.  While I
realize that we're not typically writing embedded realtime drivers in
Python, the principle remains - where possible make things as
predictable and repeatable as you can.

For reasons I am not free discuss here, I can say with some assurance
that there are real world applications where managing Python object
lifetimes is very much indicated.