Can this discussion be moved to python-ideas? Thank you.
On Thu, 24 Mar 2011 09:51:59 -0600 Jameson Quinn <jameson.qu...@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.qu...@gmail.com> > > > > > > > 2011/3/24 Brian Curtin <brian.cur...@gmail.com> > > > >> On Thu, Mar 24, 2011 at 06:40, Jameson Quinn > >> <jameson.qu...@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 > > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
