On 6/28/07, Douglas Alan <[EMAIL PROTECTED]> wrote: > "Chris Mellon" <[EMAIL PROTECTED]> writes: > > > Obviously. But theres nothing about the with statement that's > > different than using smart pointers in this regard. > > Sure there is -- smart pointers handle many sorts of situations, while > "with" only handles the case where the lifetime of the object > corresponds to the scope. >
The entire point of RAII is that you use objects who's lifetime corresponds with a scope. Smart pointers are an RAII technique to manage refcounts, not a resource management technique in and of themselves. > > To the extent that your code ever worked when you relied on this > > detail, it will continue to work. > > I've written plenty of Python code that relied on destructors to > deallocate resources, and the code always worked. > This is roughly equivilent to someone saying that they don't bother initializing pointers to 0 in C, because it's always worked for them. The fact that it works in certain cases (in the C case, when you're working in the debug mode of certain compilers or standard libs) does not mean that code that relies on it working is correct. > > There are no plans to replace pythons refcounting with fancier GC > > schemes that I am aware of. > > This is counter to what other people have been saying. They have been > worrying me by saying that the refcounter may go away and so you may > not be able to rely on predictable object lifetimes in the future. > Well, the official language implementation explicitly warns against relying on the behavior you've been relying on. And of course, for the purposes you've been using it it'll continue to work even if python did eliminate refcounting - "soon enough" deallocation of non-time sensitive resources. So I don't know what you're hollering about. You're arguing in 2 directions here. You don't want refcounting to go away, because you rely on it to close things exactly when there are no more references. On the other hand, you're claiming that implicit management and its pitfalls are fine because most of the time you don't need the resource to be closed in a deterministic manner. If you're relying on refcounting for timely, guaranteed, deterministic resource managment then your code is *wrong* already, for the same reason that someone who assumes that uninitialized pointers in C will be 0 is wrong. If you're relying on refcounting for "soon enough" resource management then it'll continue to work no matter what GC scheme python may or may not move to. > > Nothing about Pythons memory management has changed. I know I'm > > repeating myself here, but you just don't seem to grasp this > > concept. Python has *never* had deterministic destruction of > > objects. It was never guaranteed, and code that seemed like it > > benefited from it was fragile. > > It was not fragile in my experience. If a resource *positively*, > *absolutely* needed to be deallocated at a certain point in the code > (and occasionally that was the case), then I would code that way. But > that has been far from the typical case for me. > Your experience was wrong, then. It's fragile because it's easy for external callers to grab refcounts to your objects, and it's easy for code modifications to cause resources to live longer. If you don't *care* about that, then by all means, don't control the resource explicitly. You can continue to do this no matter what - people work with files like this in Java all the time, for the same reason they do it in Python. Memory and files are not the end all of resources. You're arguing against explicit resource management with the argument that you don't need to manage resources. Can you not see how ridiculously circular this is? -- http://mail.python.org/mailman/listinfo/python-list