destructors order not guaranteed?

[William S. Lear]

"Alex Martelli" <aleaxit at yahoo.com> writes:
> "William S. Lear" <rael at zopyra.com> wrote in message
> news:87hf5rdmsa.fsf at lisa.zopyra.com...
> > "Alex Martelli" <aleaxit at yahoo.com> writes:
> > > ...         Thus, [Python has] no (e.g.) dangling-references problem,
> > > but no elegant automatic-LIFO discipline, either ...
> >
> > I think the elegant automatic-LIFO discipline is very valuable.  Why
> 
> I think you've still failed to _show_ that value, beyond
> proclaiming it.  If you clarify (to yourself and to us)
> where that value comes from (in the context of Python,
> without assuming 'stack-resident' objects &c), we'll all
> be better placed to understand exactly what it IS that
> you desire, and perhaps help you obtain it.

I find it curious that you proclaim it to be an "elegant
... discipline" and then say that I must "_show_ that value".  If you
do not believe it has value why would you call it an "elegant
... discipline"?  In any case, I have in mind something like logging
events over a network when certain work has been finished.  I often
use object strict scoping and destructors to communicate the
completion of a task in this way and the LIFO order makes things work
very nicely.  In short, the "elegant automatic-LIFO discipline" (as
you put it) can be put to good use.

> > could this not be guaranteed in Python?
> 
> As I have repeatedly (and, apparently, fruitlessly) tried
> to explain, it is not even clear exactly what one should
> be 'guaranteeing'.  C++, for objects whose lifetimes are
> as dynamic as all of Python objects' are, guarantees zilch:
> once you've made an object with, say, "new foo(1)", it's
> totally up to you to "delete" that object when appropriate.

Yes, of course, but I'm obviously not talking about objects allocated
on the heap, am I?

> > If I remember correctly,
> > Frederick Lundh says that there is not even a guarantee that
> > destructors will be called.  I find this notion inelegant and
> > counter-intuitive, but perhaps my intuition is pointed in the wrong
> > direction.
> 
> You do understand that NO language on earth gives any
> "guarantee that destructors will be called" in the GENERAL
> case, right?  ...

Yes, but of course I'm not --- and have not --- been talking about the
GENERAL case.  I don't understand why you are discussion allocating
objects on the heap in C++ --- this is beyond the scope of the
discussion and entirely irrelevant.  This is not a flame war about
which language is best --- I fully understand the drawbacks and
advantages of allocating on the heap.

> [More irrelevantia snipped]...
> If Python became the only language on Earth to ensure
> destruction of _every_ object ...

No one is proposing this.  You are inventing this on your own.  I was
clearly talking about differentiating stack-based from heap-based
objects for the purposes of calling their *destructors* (note: NOT
necessarily freeing the memory associated with the objects).  Your
discussion of garbage collection is also curious to say the least, as
I don't see garbage collection as necessarily being inconsistent with
objects "allocated" on a stack and "destroyed".  I could care less,
really, if the memory itself were freed when my destructor is called
--- frankly, the interpreter can do what it likes in that regard.
However, I do find it convenient to use "destructors" in the way I
mentioned.

> destruction happens in some special order...), it
> would basically lose its current outstanding ability
> to "play well with others": no more could you have
> Python implementations that generate code for general
> existing frameworks.  Jython, for example, generates
> code for the Java Virtual Machine (JVM) from Python
> sources; Python.NET, similarly, generates MSIL code
> (Microsoft Intermediate Language -- for the MS .NET
> framework).  Both JVM and MSIL use mark-and-sweep
> garbage collection: objects to which no accessible
> reference remains MAY be finalized IF AND WHEN the
> runtime system comes around to it.  No language with
> "guaranteed-destruction" semantics can generate code
> for "first-class" (fully interoperable) objects in
> such frameworks; it will always remain a "second
> class citizen".

As I mentioned, I don't see ANY inconsistency with having
*destructors* called in a particular well-defined order.  You can do
with the memory what you like.  Shall I launch into a lecture here
asking YOU if you understand the difference?  I think I shall not play
that game, thanks though.


Bill
-- 
William S. Lear | Who is there that sees not that this inextricable labyrinth
r a e l @       | of reasons  of state was artfully invented, lest the people
z o p y r a .   | should  understand  their own  affairs, and, understanding,
c o m           | become inclined to conduct them?    ---William Godwin, 1793