From: "Martin v. Löwis" <martin at v.loewis.de>
> Marcin 'Qrczak' Kowalczyk wrote:
> >>If it involves looking at
> >>all local variables, it might be implementable, but might cause a
> >>significant slowdown even if the feature is not used.
> >
> >
> > Not just inefficient but wrong: not all such objects should be
> > finalized. They can have references stored elsewhere.
>
> I understand that is the whole purpose of the requested feature:
> to invoke a method on the object when a function completes,
> regardless of whether there are still references to the object.
Actually, what I am bringing forward does not address that case. The
implicit assumption is that the coder is sure that zero references to the
object will be left upon return from function. This is usually the case when
opening files, acquiring locks etc: if the coder wants proper cleanup, they
*have* to assume there are no references left. E.g.,
def func():
ff = file('foo.txt', 'w')
# do calls to various other functions
ff.close()
The implicit assumption is that the close() is safe to do, i.e. that none of
the functions called between the open and the close stored references. If
there are refs stored and try to write, exception will occur, in section of
program totally unrelated to func(), certainly not expected behavior by the
coder.
I think it is safe to say that in cases where deterministic "finalization"
is desired, the coder doesn't want the object to be shared, and makes the
assumption that refs aren't being stored without their knowledge. If they
are, even current idioms, like the simplistic example above, are flawed.
Oliver
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4