It may be time to PEP (or re-PEP), if only to clarify what people are actually asking for.
Brian Sabbey's example from message http://mail.python.org/pipermail/python-dev/2005-March/052202.html
*seems* reasonably clear, but I don't see how it relates in any way to
"for" loops or generators, except as one (but not the only) use case.
def add(thunk1, thunk2, other): print thunk1(1,2) + thunk2(3,4) + other
with x,y from add(100): value x*y also a,b: # yikes?? value a*b # this is thunk2
To make my own understanding explicit:
(1) Calls for "Ruby blocks" or "thunks" are basically calls for placeholders in a function. These placeholders will be filled
with code from someplace else, but will execute in the function's
own local namespace.
(2) A function as a parameter isn't good enough, because the passed-in function can't see bindings in the surrounding larger function. (It still sees the lexical scope it which it was defined.)
(3) A function as a parameter isn't good enough, because the
passed-in function can't modify bindings in the surrounding
larger function.
(4) A thunk could be used today be creating a string (rather than a pre-compiled function) and substituting in the thunk's string (rather than the code to which it would compile) before execution, though this would be ugly.
(5) A thunk *might* be do-able with exec or eval if a function's locals were still a dictionary.
notice that while closures with the current semantics of def cannot rebind, the internal mechanism for closures is perfectly capable of supporting rebinding. So thunks could be function objects.
(6) This has nothing whatsoever to do with for loops or generators, except as a common use case. In particular, thunks may be used to lock/unlock or unwind-protect some resource. Generators are not the only place this is needed, but they have made the "what do you mean, __del__ might never get called?" problem even worse, and Ruby often solves these with a Ruby Block.
(7) A __leave__ or __exit__ special method really turns into another
name for __del__. It might still be useful if it came with semantics
of "I explicitly don't care what order cycles are broken; call me as
soon as my object is garbage and who cares if it gets resurrected."
There have been recipes (from Tim?) for emulating this by using a proxy to the resource, so that no __del__ cycles can form.
-jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
