[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