fork()

[Hisao Suzuki]

In article <u3d7yzn1np.fsf at ares.sys1.ngo.okisoft.co.jp>, I wrote:
| Python's __del__ is conceptually equivalent to C++'s destructor.

In article <000901beb6ef$f73c0f60$069e2299 at tim>,
"Tim Peters" <tim_one at email.msn.com> wrote:
> This is true, but Python has nothing equivalent to the C++ "delete"
> operator, and *everything* in Python acts as if it had been created by the
> C++ "new" operator. Stroustrup is only talking about C++ objects explicitly
> created by "new" but never explicitly destroyed by "delete".  C++ has
> several other ways for objects to come in and out of existence that don't
> involve "new" or "delete" (block-scope auto; static; anonymous temps in
> expressions), and rigidly defines when destructors are invoked for those
> (more rigidly than Python, which actually opens some uses for destructors in
> C++ that can't quite be done in Python).

You miss the point.

| (Otherwise we would not rely on self.close() at __del__ in
| Lib/tempfile.py!)  The above phrase `(be) never deleted' for C++
| can be safely translated as `(be) part of cycles' for Python.
| Thus, Guido's idea is quite consistent and orthodox in this
| regard.  It will be acceptable to most of the current working
| Pythoneers, including me, even if they are not fans of the Lots
| of Intolerable Stupid Parentheses ;-)

> If there's an analogy to be drawn here, it would be that since everything in
> Python acts as if created by C++ "new" and can never by explicitly
> destroyed, Stroustrup is arguing that Python should never invoke a
> destructor period.

It sounds like a theoretical nonsense.

> The contexts are so different, though, that this analogy is as silly as it
> sounds <wink>.

By your saying, object construction in Python corresponds to
`new' operation in C++, doesn't it?  When you program something
in C++, you use `delete' to destroy the object that you have
`new'ed, don't you?

And _what_ do you do to destroy the object that you have
constructed in Python?  You remove all the references to the
object by assigning another object to each variable or attribute
that refers to the object, or by `del'ing such variables, etc.,
don't you?

Certainly C++'s `auto' variable disappears automatically upon a
block exit.  It corresponds to disappearance of a (sole, in
typical case) reference from a local variable to the object upon
a function return in Python.  In typical case, the object loses
all the references and is destroyed.  Whether it is the typical
case or not is usually obvious when you program in Python.

Thus, on programmers' view, `delet'ion of a `new'ed object and
disappearance of an `auto' variable in C++ are conceptually
equivalent to removing all the references to an object in
Python.  Indeed the Python Reference Manual specifies a fairly
weaker semantics in this regard, but some (or rather most?) of
the current working Python programmers _rely_ on the current
implementation's semantics, you know.

If an object is part of a cycle, the object will never lose the
reference(s) to it.  So the phrase `(be) never deleted' for C++
can be safely translated as `(be) part of cycles' for Python.
You see?


| Further the C++ 3rd Ed. says:
|    "It is possible to design a garbage collector to invoke the
|     destructors for objects that have been specifically
|     `registered' with the collector.  However, there is no
|     standard way of `registering' objects.  Note that it is
|     always important to destroy objects in an order that ensures
|     that the destructor for one object doesn't refer to an
|     object that has been previously destroyed.  Such ordering
|     isn't easily achieved by a garbage collector without help
|     from the programmer."

> Java solved that one -- for all the good it did <wink>.

Are you referring to java.lang.ref.PhantomReference of Java2?
Otherwise you wholly miss the point.  The traditional mechanism
of finalization in Java serves as only a safety net at _best_.


| As for a reference to option (b), see, say, R. Kent Dybvig's
| ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz
| which I have mentioned before in this newsgroup, though it is
| written for Scheme and actually the coming version of GNU guile
| implements guardians, i.e. `registration' servers described in
| it.  Note that the guardians may be implemented somehow in 100%

> Indeed a very general mechanism!  Combining it with sensible __del__ rules
> for non-cycles could well lead to something better than Scheme and Python
> <0.5 wink>.

The idea of guardians is not so particular to Scheme.  It might
be safe to say that Scheme is a language that happened to be
used.  Needless to say, it is important to keep _Python_ simple,
handy, and consistent.

| it.  Note that the guardians may be implemented somehow in 100%
| pure Python even if it doesn't have a garbage collector.  The
| sys.getrefcount built-in function will be used then.

> Don't think so.  Knowing the refcount doesn't tell you whether a thing is
> trash, e.g.
> 
> class A: pass
> a = A()
> a.seq = [a] * 1000000
> del a
> 
> and there's no general way to trace the objects reachable from a given
> object without a protocol for the reachable objects to cooperate in
> revealing who is directly reachable from them (it can be laboriously
> accomplished for objects of  builtin types now by exploiting deep knowledge
> of the way they happen to be implemented, but toss in an extension type and
> you're dead).

However, the programmer often knows the expected refcount of the
object or the aggregation object of several objects when it
becomes unreachable from any other (aggregation of) objects.
Usually (though not always) he/she can pass the expected
refcount to the guardian.

> In any case, implementing M&S in Python is even slower than implementing it
> in C <wink>.

Of course.

And it is our usual practice to make prototypes in Python first,
if possible, to experiment on some ideas, isn't it? :-)

--===-----========------------- Sana esprimo naskas sanan ideon.
SUZUKI Hisao            suzuki611 at okisoft.co.jp, suzuki at acm.org.