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