Builtin dict should be callable, since a dict defines a function
Bengt Richter
bokr at oz.net
Fri Dec 20 12:07:18 EST 2002
More information about the Python-list mailing list
Fri Dec 20 12:07:18 EST 2002
- Previous message (by thread): Builtin dict should be callable, since a dict defines a funct ion
- Next message (by thread): Builtin dict should be callable, since a dict defines a function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 20 Dec 2002 13:16:24 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote: >Bengt Richter wrote: >> I recognize that distinct interfaces are often expressed with obj() vs obj[] >> and they very usefully lead to different aspects of the object. > >Not to mention "obj." Every object is a function, too, taking its >attributes as arguments and returning a value (or AttributeError). > Sure, most everything you can do with anything has a .__xxx__(...) spelling. (Easy to say now ;-) >Your misconception is that you want to make one functional access to an >object the preferred one. This is confusing: Not to be confrontational, but what gives you the idea that I want to make it preferred? Or do I miss your meaning? No, I think adict[key] will be preferable most of the time. I was just forgetting that adict.__getitem__(key) functionally spells what I wanted to spell with adict(key), and I can pass the bound method/method wrapper object where I wanted to pass the dict itself. Even so, I still don't see the objection to the nicer spelling, since that syntax is not doing anything by default. > >In the face of ambiguity, refuse the temptation to guess. >There should be one-- and preferably only one --obvious way to do it. That can cut both ways ;-) Since a dict and a function both have sensible function interpretations, we shouldn't have to write a=foo(dct.__getitem__); b=foo(fcn) where sensible thing is to use "one way"(tm) to write both calls ;-) a=foo(dct); b=foo(fcn) where e.g., def foo(obj): return obj() > >IOW, why should d(key) be the same as d.__getitem__(key), instead of, >say, d.get(key); the latter has even the advantage of being a total One defines a (non-exception-raising) function mapping finite sets 1:1, the other maps the rest of the universe to any selected element of the universe as well. ISTM the simpler is the more natural default, plus the second mapping definition is not defined by the object, but effectively added by the caller at each call time, except for the default default of None. >function. This also points to a solution to your original question: If >you have a dictionary and need a callable, use d.__getitem__. > Well, that last was pretty much a touché & d'oh, Martin, although Holger beat you to it by an hour and twenty minutes ;-) But I still would ask the question, "Why should an object which has an unambiguous, simple, sensible, intuitively obvious functional interpretation refuse to be called as a function (i.e., provide the __call__ method wrapper) if this is not already defined ?" I would think that's in the spirit of unification, not anarchy ;-) Further, I would be looking for any really sensible uses of existing "trailer" notation with respect to any standard object. E.g., [i:j] might seem weird on a function object, but what about a generator? Regards, Bengt Richter
- Previous message (by thread): Builtin dict should be callable, since a dict defines a funct ion
- Next message (by thread): Builtin dict should be callable, since a dict defines a function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list