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

Jameson Quinn jameson.quinn at gmail.com
Thu Mar 24 16:51:59 CET 2011

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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/89deaf21/attachment.html>

More information about the Python-Dev mailing list