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