Jeff Schwab <[EMAIL PROTECTED]> writes: > some_class().method() > The method body could create an external reference to the instance of > some_class, such that the instance would not be reclaimed at the end of > the statement.
Yes. Therefore there is no way to predict if the object will be be freed, without intimate knowledge of the semantics of the class and method. > It's not "my" scheme. I got it from Martelli. Well, he's a very wise and knowledgable Pythonista, so I hope he's using the "with" statement by now. > This is a special case of the reference count being 1, then > immediately dropping to zero. It is simple and convenient. The > approach is, as you rightly point out, not extensible to more > complicated situations in Python, because the reference counting > ceases to be trivial. It's not trivial even in the simplest case, like the one you cited of opening a file. Maybe you've shadows the "open" function to keep a cache of file contents or something. > The point is that once you tie object lifetimes to scope, rather than > unpredictable garbage collection, you can predict with perfect ease > and comfort exactly where the objects are created and destroyed. Sure, fine, Python does that with the "with" statement and C++ does it with class destructors on automatic variables. The old kludge of some_class().method() creates an instance of some_class but does NOT tie it to a scope, for the reasons we've discussed. > That's true of the current language. I don't have enough experience > with "with" yet to know whether it's a realistic solution to the > issue. IMO, they are at least preferable to Java-style > finally-clauses, but probably not a replacement for C++-style RAII. It is a more general version of what C++ does, as I understand it. -- http://mail.python.org/mailman/listinfo/python-list
