Oliver Schoenborn wrote:
> 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.
Hmm. Assumptions are irrelevant for language semantics specification,
unless they can be proven correct. It is very easy to come up with
examples where the assumption is not met. I'd like to know what the
semantics of your proposed mechanism is before I can understand in what
cases it is useful.
In the particular case of Python, there is *no* guarantee that there
are zero references to an object when the function returns, as the
object may be referred-to in a traceback.
> 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.
Your idiom is flawed, as you need to consider the case of exceptions.
The Python idiom really reads this way:
def func():
ff = file('foo.txt', 'w')
try:
# do calls to various other functions
finally:
ff.close()
Regards,
Martin
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