In article <[email protected]>,
Ethan Furman <[email protected]> wrote:
>-=-=-=-=-=-
>
>On 01/24/2015 11:55 AM, Chris Angelico wrote:
>> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman <[email protected]> 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@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
--
https://mail.python.org/mailman/listinfo/python-list
