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

Jameson Quinn jameson.quinn at gmail.com
Thu Mar 24 18:37:37 CET 2011


OK, fair enough. People don't like this. So let me back up a step.

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.

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.

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.

So, what about a method on (certain?) dict objects to return the
attr-wrapped version of the dict. That is:

class AttrDict(object):
   def __init__(self, dict):
     self.__dict__ = dict

class WithAttrDict(dict):
    @cached_property #what it sounds like - implementation not shown
    def att(self):
        return AttrDict(self)

I'd like all the dicts and sub-dicts which come from the standard json
library to be WithAttrDicts, so I can write:

parsedjson.att.spam.att.eggs #I'd love to avoid the second "att."
   #but I don't want to complicate this proposal further.

instead of

parsedjson["spam"]["eggs"].

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.

Jameson

2011/3/24 Brian Curtin <brian.curtin at gmail.com>

> On Thu, Mar 24, 2011 at 10:51, 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.)
>>
>
> I can certainly see use cases for this, but none generic enough for the
> standard library.
>
> 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:
>
>     print(config..bitbucket.org..user)
>     *boom*
>
> 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?
>
> 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.
>
> In the end, it's syntactic sugar for a limited set of applicable cases.
>
>
>
> [0] http://docs.python.org/release/3.2/library/configparser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110324/4cb71e6e/attachment.html>


More information about the Python-Dev mailing list