From: Bill Soudan Date: Thu Dec 4, 2003 21:56:46 Europe/London To: Michael Hudson Subject: Re: PEP 310/object lifetimes? On Thu, 4 Dec 2003, Michael Hudson wrote: > More or less what I guessed. Which ICQ client do you use now? I've > settled on centericq for the time being. I don't use IM in general much anymore. I find it too distracting and too much of a temptation if I'm trying to get work done - I'm terrible at multitasking! When I use one (at home sometimes) it's AOL IM, since everyone in my social circle has an account there. Usually Gaim, but sometimes naim if all I have is a text console. Though I think I heard somewhere ICQ/IM are completely interoperable now? > [Locker class] > > Well, false is perhaps the wrong way of putting it... contrived, maybe. Interesting the different perspectives :) > I guess you could say that part of the art of programming language > design is deciding which notions to conflate in this way and which not. Right, I agree. I suspect we think about the whole RIAA concept from different angles, probably because of different programming backgrounds? I try to explain mine below. > You can make a case for the conflation of holding resources and > lifetimes of objects, but I'm not sure I buy it. I've never honestly thought about it much, just used it, but I've taken a step back and tried to analyze it after your last email. I still find it very natural if you consider the object as a gateway to a resource, think file handle in C or file object in Python. You only have access to the resource when the object exists. Destroying the object does not destroy the resource, merely, your ability to access it. The method you propose in PEP 310 introduces an additional layer from my perspective: 1) __init__: create resource access object 2) __enter__: 'enter' resource access object (acquires access key) 3) ... 4) __exit__: 'leave' resource access object (releases access key) 5) __del__: destroy resource access object vs. 1) __init__: create resource access object (acquires access key) 2) .. 3) __del__: destroy resource access object (releases access key) What value does the extra layer add? To me, it's unnecessary complexity, because the function of acquiring and releasing the access key can be served _just as well_ by the mechanism provided by the constructor and destructor of a scoped object. Assuming a version of Python that provides the ability to control an object's lifetime, of course. And like I think I mentioned before, it also neatly solves your open issue regarding existing objects (__exit__ = close) without any code changes whatsoever. Provided they have properly implemented __del__ methods, anyway. >> In my specific case, poorly written C++ code I can't change that does >> things in its destructor. > > Oh, *ick*. For this case couldn't you implement an extension type that > did roughly > > delete self->cpp_object; > > in an __exit__ method? I did a similar work-around, but I would prefer a version of C++'s delete with the same semantics in Python if possible. So for this particular case, I guess I'm really asking for a version of 'del object' that will always invoke __del__, this is a different issue than your PEP. I think the same exception deal could be applied here too, if there's another reference when you want the object to go away, throw an exception. >> there's still the issue of programmer error. I'd be nice have an >> explicit way to say 'this object will no longer exist here'. > > I guess I have a lispers approach to this: view memory as infinite and > assume the implementation does enough behind its back to maintain this > illusion so long as not too many objects are actually live. If you seperate the memory and object concepts, an object can cease to exist even though memory is still allocated for it. What happens with the memory is an implementation detail, as far as I'm concerned. >> 2) throw an exception at the end of the with block if the object >> cannot be >> deleted. > > Given that it's the only sane possibility, that's good :-) > > Even then, it's probably impossible in Jython, unless I'm missing > something (and it would seem to permanently limit Python's GC choices). I noticed this too while I was doing more research last week. Ugh. My only thought was similar to the above - seperating the object and memory concepts. I suspect that Java's JVM ties the two together, so this may not be possible. I know very little about Java in general and even less about how the JVM is implemented, though. How important is compatability w/ Jython? Is it just a happy coincidence Python can be implemented so well on a JVM, or has it become a Python design goal? Speaking of research, I also tried to get in touch with Paul but haven't had any luck. I'll probably post something up on python-dev shortly. > I agree they work well there. > > OTOH, I'd feel bad encouraging people to write more __del__ methods > given the irritating effects they can have (preventing collection of > cycles being the main one). Irritating effects? I'm not familiar with any... preventing collection of cycles? Not sure what you mean there. Reading over the Python language specification, I see __del__ is particularly hairy in general. I'll have to think about it some more. Garbage collection puts a whole different spin on these things, and to date I've spent more time enjoying it than thinking about it. Thanks for the comments, Bill