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
