destructors order not guaranteed?

[Alex Martelli]

"Helen Dawson" <helend at accessone.com> wrote in message
news:3A050D2A.3ECF65D6 at accessone.com...
> Here's the shortened version of Alex's post:
>
> It can't be done, it can't be done, nobody wants it any
> way, it can't be done, it can't be done.
>
> Here's how you do it.

That's a fair summary of many of the technical discussions
I've had with managers and colleagues over the years (and
decades), yes.  They state "we need X", I answer "you
can't have X, it's impossible because of [blah blah blah],
and besides you *don't* need X, because Y [which is
obviously easy] would be almost as good/just as good/
even better".  It does often turn out that they did not, in
fact, need X -- rather, they needed a solution to some
problem Z, which Y or some variant Y' meets decently.
(It's worse when X _is_ feasible -- at great cost/effort/&c --
and ends up getting implemented in lieu of the trivial,
almost-as-good Y:-).

I guess I could generalize that "what people ask for is
[almost] NEVER what they want"?-)


> Okay, I'm just kidding. But the truth in that kidding is
> that I suspect that your solution - a stack class with
> a new() method, that records objects in order, and
> deletes them in reverse order is exactly what was
> requested.
>
> Yes, if other objects have references to them, they
> won't get destroyed. You know what - that's okay.
> For those times when LIFO delete order matters
> it will invariably be true that there are no other
> references to them.

Don't you just wish it were so.  You'd be surprised to
see how many dangling-pointers-problems just turned
into leaking-resources-problems when experimentally
recoding some of our stuff from C++ to Java; it seems
that programmers can hardly resist the temptation to
stash away a reference to an open DB connection, for
example, somewhere in their subsystems, where it stays
long after there's any need for it any more.  In C++ this
shows up as an occasional horrible crash in some 'stable'
subsystem, many months & releases later, when the
not-valid-any-more pointer turns out to get used.  In
Java or Python, as coded by programmers coming from
C++ and used to leaving finalization to destructors, it
shows up sooner, with mysterious resource leaks (that's
when the request generally comes "we need a DBMS that
will support unlimited open connections"...:-).  Once the
Java or Python programmer learns to do finalization more
explicitly in a finally-clause, things get better again (no
leaks, and when the still-valid reference to a now-closed
DB connection gets used, a clean exception results, and
it's generally not hard to debug it).

Now IF there was some way to ensure that the references
given out are only "weak" ones, _then_ perhaps finalization
automatisms could work as well as explicit closing in a
finally clause, and the elegance could turn into usefulness
again... but that seems pretty far from where Python or
Java are going, sigh.


> I suspect that the original poster would now want
> to phrase his request as:
>
> "I wish Python automatically dealt with local
> variables in the way that Alex's Stack() class
> does"
>
> Python programmers that come from a C++
> background, like myself, probably intuitively
> assume that it behaves like that. I did. I
> appreciate this discussion because I now have
> a better understanding of how it does behave,
> and why.

Hey, that's good, then!  Including the "why" there
is no implicit promise in Python to record the
'registration-order' of variables (local or otherwise)
and take it into account on stackframe closure?  To
summarize, it's because this overhead buys you 'not
much' -- in particular, it doesn't really make it safe
to rely on destructors to do the things you should
be doing in finally-clauses.

It IS elegant, though...:-)


Alex