Alternative to multi-line lambdas: Assign-anywhere def statements
Albert van der Horst
albert at spenarnc.xs4all.nl
Wed Feb 11 08:04:22 EST 2015
In article <mailman.18121.1422151185.18130.python-list at python.org>,
Ethan Furman <ethan at stoneleaf.us> wrote:
>-=-=-=-=-=-
>
>On 01/24/2015 11:55 AM, Chris Angelico wrote:
>> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>> If the non-generic is what you're concerned about:
>>>
>>> # not tested
>>> dispatch_table_a = {}
>>> dispatch_table_b = {}
>>> dispatch_table_c = {}
>>>
>>> class dispatch:
>>> def __init__(self, dispatch_table):
>>> self.dispatch = dispatch_table
>>> def __call__(self, func):
>>> self.dispatch[func.__name__] = func
>>> return func
>>>
>>> @dispatch(dispatch_table_a)
>>> def foo(...):
>>> pass
>>
>> That's still only able to assign to a key of a dictionary, using the
>> function name.
>
>This is a Good Thing. The def statement populates a few items, __name__ being one of them. One
>of the reasons lambda
>is not encouraged is because its name is always '<lambda>', which just ain't helpful when the
>smelly becomes air borne! ;)
That's the reason why my ideal Python doesn't attach a name to a lambda denotation:
x -> x**2
is a function object, not something that has a name.
It is not until we assign the object to a name (which becomes thereby a function)
that the __name__ thingy comes into play, like so.
f = x->x**2
or
f = x-> return x**2
for those who don't like Algol68
I've heard arguments that with -> the __name__ is not filled in correctly.
I can't see why the parser would understand more easily
def f(x):
return x**2
than
f = x->
return x**2
[I'm striving for simplification, doing away with both the lambda and
the def keywords. This is not a proposal for a language change, I'm
trying to explore possibilities here. ]
>
>--
>~Ethan~
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
More information about the Python-list
mailing list