[Python-Dev] Dict access with double-dot (syntactic sugar) (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Thu Mar 24 16:57:25 CET 2011

Can this discussion be moved to python-ideas? Thank you.

On Thu, 24 Mar 2011 09:51:59 -0600 Jameson Quinn <jameson.quinn at gmail.com> wrote:

Consider:

def fun1(argument): print argument1 fun1(argument="spam") def fun2(**kw): print kw["argument"] Why should I need quotes around "argument" in just one of those places? What if I left them off, and there happened to be a global variable named "argument"? Why shouldn't I be able to say: def fun2(**kw): print kw..argument (in real life, there would be a try... except block in case there was no argument, I'm just showing the simplest case here.) Jameson 2011/3/24 Jameson Quinn <jameson.quinn at gmail.com> > > > 2011/3/24 Brian Curtin <brian.curtin at gmail.com> > >> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn <jameson.quinn at gmail.com>wrote: >> >>> "class attrdict" is a perennial dead-end for intermediate pythonistas who >>> want to save 3 characters/5 keystrokes for item access. Other languages such >>> as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so >>> why not python? Well, there are a number of reasons why not, beginning with >>> all the magic method names in python. >>> >>> But saving keystrokes is still a reasonable goal. >>> >> >> Code is read far more often than it is written, so readability tends to >> count more than most other metrics. >> >> So what about a compromise? Allow "somedict..foo", with two dots, to take >>> that place. It still saves 2 characters (often 4 keystrokes; and I find even >>> ', "[", or "]" harder to type than "."). >>> >> >> I don't see the benefit, but maybe it'll save a few bytes in file size. >> Anyone reviewing your code now has to think "does this need one or two >> dots?" >> >> Anyways, why not just do something like this: >> >> class AttrDict(dict): >> def getattr(self, attr): >> return super(AttrDict, self).getitem(attr) >> >> >>> d = AttrDict() >> >>> d["a"] = 1 >> >>> d.a >> 1 >> > > There are a few reasons not to do it your way. For one, you could easily > forget about one of the built-in dict methods (e.g. d.get != d["get"]). For > another, if you look on the web, you'll find at least 15 different recipes > for that thing you just made, several of which have more-or-less subtle > errors waiting to get you. Furthermore, the whole point is to have this > available for built-in dicts. Say you get a dict as json - you can either > subclass your own json decoder, with all the pitfalls, or you can explicitly > pass the decoded dict to AttrDict, causing an extra object to be created and > obfuscating your code. And finally, who wants to copy that AttrDict code for > the 137th time? > > As for the question of "one or two dots", it's exactly the same question > you face now with "dot or bracket", so I don't see the problem. > > It's not merely a matter of saving keystrokes. To me, it would be actually > easier to read code in this style. When I'm doing things like accessing my > json data, that is essentially attribute access; why should my syntax > colorer color it the same as my UI strings? > > In sum: > -Saves keystrokes > -saves bugs from miscooked recipes > -faster and less memory than any such recipe > -more-readable code > -very low-risk for old code > > Jameson >

More information about the Python-Dev mailing list