[Python-ideas] One more time... lambda function <--- from *** signature def.

Ron Adam ron3200 at gmail.com
Wed Mar 5 06:25:42 CET 2014



On 03/04/2014 07:05 PM, Andrew Barnert wrote:
> On Mar 4, 2014, at 14:31, Greg
> Ewing<greg.ewing at canterbury.ac.nz>  wrote:

>>> Steven D'Aprano wrote:

>>>>> What I have in my head is some vague concept that the Python
>>>>> evaluation rules will somehow know when to evaluate the thunk
>>>>> and when to treat it as an object, which is (as I understand it)
>>>>> what happens in Algol.

>>> But Algol has the benefit of static typing -- the procedure being
>>> called explicitly declares whether the argument is to be passed by
>>> name or value. Python has no idea about that at compile time.

> This is the main reason I think it's more productive to think of this in
> terms of Lisp-style quoting than Algol-style thunks. The fact that
> quoting/thunking gives you a code object instead of an AST (sexpr) is
> not significant here* (unless we're also considering adding macros). The
> fact that it gives you a first-class value, and that we can't use the
> "implicit casting" syntax that comes with static typing to magically
> evaluate the object at the right time, is critical.

> This is basically the same problem I described trying to implement
> Boost-style auto lambdas in Python without C++-style implicit cast from
> lambda to function.

In a experimental language I'm writing, I use a concept I call "Context 
Resolution" to resolve objects to expected kinds of objects.  The expected 
type/kind is determined in the context of how things are used together 
rather than by how they are defined.  (That allows everything to be 
objects).  Keywords, Names, Expressions, and CodeBlocks, etc...


In python it would probably depend on AttributeError instead of the type.

If an object doesn't have the needed attribute, then it could try calling a 
different method, possibly __resolve__.  Then retry the attribute lookup 
again on the result.

If there's no __resolve__ attribute, then the AttributeError would be 
raised as usual.  The chained __resolve__ resolution attempts would also 
give a useful exception backtrace.

Cheers,
    Ron



More information about the Python-ideas mailing list