[Python-3000] Wild idea: Deferred Evaluation & Implicit Lambda
Josiah Carlson
jcarlson at uci.edu
Wed May 31 08:52:06 CEST 2006
Talin <talin at acm.org> wrote:
> Josiah Carlson wrote:
> > It's all a matter of semantics. If I tell you "I'm going to implement
> > deferred/promise/etc., as a callable", and as long as I tell you the
> > semantics of that call, it will be clear what I mean. Let's actually go
> > through the trouble of defining it:
> >
> > If I call something a "future", a "promise", or a "deferred", what I
> > mean is that the actual evaluation of an arbitrary sequence of
> > statements and/or expressions will be "deferred" to the "future" and
> > that I "promise" to evaluate them if given the proper opportunity. How
> > I will define such a thing is to say that any callable that takes zero
> > arguments is a "future", a "promise", or a "deferred", and that calling
> > this callable without any arguments will evaluate the specified
> > statements and/or expressions.
> >
> > Now that I have sufficiently specified, please explain to me how a new
> > syntax would improve the current situation?
>
> You're missing a crucial point: The whole idea of 'promise', as I
> understand it, is that it works with functions that aren't expecting a
> callable.
So you use the 9-line promise that Alex posted.
[snip]
> Now, I don't have a problem with the -1, except to say that nothing
> concrete has actually been proposed yet, so there's nothing to vote on.
> (Unless you are voting to kill the discussion.)
I'm voting a -1 on the proposed feature addition of a 'deferred
execution' mechanism because such is already available with minimal
effort in current Python, either explicitly via semantic definition (I
know my deferred is a callable) or by using a __getattribute__ hook like
Alex specified, which uses the "I know my deferred is a callable"
internally.
- Josiah
More information about the Python-3000
mailing list