does python have useless destructors?

Isaac To kkto at
Fri Jun 18 12:52:36 CEST 2004

>>>>> "Marcin" == Marcin 'Qrczak' Kowalczyk <qrczak at> 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
    myvar = new file
    line = myvar.readline()
    if myvar:

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.


More information about the Python-list mailing list