OK, fair enough. People don't like this. So let me back up a step.<div><br></div><div>Clearly this is intended for using with things that you get as a dictionary, but which really should be namespaces. The top two cases of that are parsed json objects and **kw arguments.<br>
<div><br></div><div>I suppose that, if I cared to, I could write a decorator that passed a wrapped object in kw arguments. Also, the whole point of **kw is that you don't know ahead of time exactly what's in there, so the usefulness is limited.</div>
<div><br></div><div>But definitely, it looks wrong to me to be putting the attribute names of my json in quotes. Again, I could make a wrapper, and tinker with my json parser (subclass it or whatever) so that it passed back by default. But I think that this use case is common enough with json (often, you know exactly what should be in there) that it should be built into the standard json library.</div>
<div><br>So, what about a method on (certain?) dict objects to return the attr-wrapped version of the dict. That is:</div><div><br>class AttrDict(object):<br> def __init__(self, dict):<br> self.__dict__ = dict</div>
<div><br></div><div>class WithAttrDict(dict):</div><div> @cached_property #what it sounds like - implementation not shown</div><div> def att(self):</div><div> return AttrDict(self)</div><div><br></div><div>I'd like all the dicts and sub-dicts which come from the standard json library to be WithAttrDicts, so I can write:</div>
<div><br></div><div>parsedjson.att.spam.att.eggs #I'd love to avoid the second "att." </div><div> #but I don't want to complicate this proposal further.</div><div><br></div><div>instead of</div><div><br>
</div><div>parsedjson["spam"]["eggs"].</div><div><br></div><div>I'd love it if there were a one-or-two-letter property name to use instead of ".att" (".s", by analogy with english apostrophe-s?). And I'd even love it if the built-in dictionary object had such a property, even if it had a long name ("{'spam':'eggs'}.as_attributes.spam == 'eggs' "). That latter thing could, in theory, break working code... but only if you're using the same attribute name to duck-type a dictionary subclass, which I'd bet heavy odds has not been done for the given attribute name or any reasonable substitute.</div>
<div><br></div><div>Jameson</div><div><br></div><div><div class="gmail_quote">2011/3/24 Brian Curtin <span dir="ltr"><<a href="mailto:brian.curtin@gmail.com">brian.curtin@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Thu, Mar 24, 2011 at 10:51, Jameson Quinn <span dir="ltr"><<a href="mailto:jameson.quinn@gmail.com" target="_blank">jameson.quinn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Consider:<div><br></div><div>def fun1(argument):</div><div> print argument1</div><div><br></div><div>fun1(argument="spam")</div><div><br></div><div>def fun2(**kw):</div><div> print kw["argument"]</div>
<div><br></div><div>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:</div>
<div><br></div><div>def fun2(**kw):</div><div> print kw..argument</div><div><br></div><div>(in real life, there would be a try... except block in case there was no argument, I'm just showing the simplest case here.)</div>
</blockquote><div><br></div></div><div>I can certainly see use cases for this, but none generic enough for the standard library.</div><div><br></div><div>Let's take the configparser module for example: in 3.2 ConfigParser objects can now be accessed like dictionaries. Looking at the examples in the documentation [0], an immediate problem comes to mind:</div>
<div><br></div><div> print(config..bitbucket.org..user)</div><div> *boom*</div><div><br></div><div>If you're going to be doing attribute access, it's likely that you know the name of the attribute -- you wrote the code knowing what to expect in the first place. If you know the names of the attributes you're going to be dealing with, why not just store them in a class, or even a class with __slots__ defined for each attribute?</div>
<div><br></div><div>The double-dot notation will only work when you already know the key. When iterating over keys, you're going to resort back to dict[key] or getattr(dict, key) to get the value.</div><div><br></div>
<div>In the end, it's syntactic sugar for a limited set of applicable cases.</div><div><br></div><div><br></div><div><br></div><div>[0] <a href="http://docs.python.org/release/3.2/library/configparser" target="_blank">http://docs.python.org/release/3.2/library/configparser</a></div>
</div>
</blockquote></div><br></div></div>