Talin <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
