Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Jeff Schwab <jeff at schwabcenter.com> 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.