Python vs Java garbage collection?

[Isaac To]

>>>>> "Antonio" == Antonio Cuni <cuniREMOVE_THIS at programmazione.it> writes:

    >> 2) __del__() would get called again when memory is actually
    >> reclaimed.  Therefore, your feature would be much safer if it called
    >> another special function - say close() or dispose() at the end of the
    >> block.

    Antonio> I can think to something totally different: for example an
    Antonio> "auto" object couldn't be used as an r-value; such a check
    Antonio> could be partially done a compile-time.  But what to do with
    Antonio> parameter to function? There should be a way to assure that a
    Antonio> function doesn't store anywhere an "auto" object passed as a
    Antonio> parameter; e.g. we could disallow parameter-passing unless the
    Antonio> function declares its arguments "auto".

The burden should be left to the programmer rather than put into the
language.  I got the idea that

  def foo():
    ... auto(XXX) ...    # E.g., a1 = auto(XXX), or a1 = [auto(XXX)]
    ...
    ... auto(YYY) ...
    ...
  # end of foo

is just a clean (and perhaps more efficient) alternative for the more
verbose code

  def foo():
    _t1_ = XXX
    try:
      ... _t1_ ...     # E.g., a1 = _t1_, or a1 = [_t1_]
      ...
      _t2_ = YYY
      try:
        ... _t2_ ...
        ...
      finally:
        try:
          _t2_.__cleanup__()
        except:
          pass
    finally:
      try:
        _t1_.__cleanup__()
      except:
        pass
  # end of foo

If the programmer does write the more verbose code, and t1/t2 does get
another reference elsewhere in the try part, the program is still screwed
up.  (But it is not really that bad: at least the "elsewhere" has a way to
check that the reference is already cleaned.)  So this "feature" should
remain there even if the auto keyword is introduced.

If the language enforces that t cannot be referenced somewhere else, there
will be a lot of cases when the programmer wants to use "auto" but the
language forbid that.  In fact, what the programmer wants to do might
actually be legitimate.  E.g., put it in a dictionary for a while for its
own use, and after that remove the dictionary.  And preventing t from being
used as an r-value does not stop that either.  Even if you call something
like a.xyz(), within the method xyz one can still get the reference of a
using self, and can still store it somewhere global.  In short, it introduce
problems without actually solving some.

    >> 3) There is probably a way to do what you want without additional
    >> syntax:
    >> 
    >> def foo(): mymutex = auto(acquire_mutex()) myfile =
    >> auto(open(filename,'w') mysocket = auto(open_socket()) do_stuff()

    Antonio> I can't think of any way to do what I want using this syntax:
    Antonio> what are you thinking of?

Avoid necessitating a modification to the parser; and emphasizing that
"auto" is something about an object, not about a variable, I think.

Regards,
Isaac.