Home Original page

does python have useless destructors?

Isaac To kkto at csis.hku.hk
Fri Jun 18 06:52:36 EDT 2004 
>>>>> "Marcin" == Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> writes:

    Marcin> What would happen when you store a reference to such object in
    Marcin> another object? Depending on the answer, it's either severely
    Marcin> limited (you can introduce no abstractions which deal with files
    Marcin> somewhere inside), or as inefficient as reference counting.

    Marcin> The only way is to somehow distinguish variables for which
    Marcin> objects they point to should be finalized, from plain
    Marcin> variables. Not objects but variables. try...finally and with are
    Marcin> examples of that.

If I understand it correctly, PEP 310 doesn't deal with that use case at
all.  In my opinion the language shouldn't try it.  Just let the program
fail.  Treat programmers as grown men who will not try to break things on
purpose.  You can always close a file and then continue to read it.  All the
system do is to give you an exception.  If we can accept this, why we worry
that much if the construct close the file too early if a reference remains
when the function close?  An "auto" or "function scoped" object is simply a
means to simplify functions, i.e., let you write

  auto myvar = new file
  line = myvar.readline()
  ...
  # ignore the difficulty of closing it

rather than

  myvar = None
  try:
    myvar = new file
    line = myvar.readline()
    ...
  finally:
    if myvar:
      myvar.close()

The only purpose is to simplify the program.  We shouldn't (and actually
won't be able to) add extra responsibility to it, e.g., make sure it is
reference counted so that the file is closed only when no more reference
remains.  If the second program above doesn't do that, we shouldn't expect
it either in the first program.  Just throw an exception whenever somebody
wants to exceed the capability of the construct.

Regards,
Isaac.
More information about the Python-list mailing list