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. -- https://mail.python.org/mailman/listinfo/python-list
