Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!newsfeed0.kamp.net!newsfeed.kamp.net!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.86.MISMATCH!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <70CF795C-8494-48CF-A5F8-3D3F8FE3AE95@gmail.com>
References: <436419A8-6CD1-43DA-AC5E-A2E974AD585E@gmail.com> <CALwzid=W=R3A9nS1ZFUNduR0WRdMnLdu2g9q+E753DSfEUBy8Q@mail.gmail.com> <70CF795C-8494-48CF-A5F8-3D3F8FE3AE95@gmail.com>
From: Chris Kaynor <ckaynor@zindagigames.com>
Date: Wed, 4 Feb 2015 12:45:51 -0800
Subject: Re: pymongo and attribute dictionaries
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.18475.1423082780.18130.python-list@python.org>
Lines: 120
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:85229

On Wed, Feb 4, 2015 at 12:16 PM, Travis Griggs <travisgriggs@gmail.com> wro=
te:
>
>> On Feb 4, 2015, at 9:22 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>
>> On Wed, Feb 4, 2015 at 9:50 AM, Travis Griggs <travisgriggs@gmail.com> w=
rote:
>>> I really like pymongo. And I really like Python. But one thing my finge=
rs really get tired of typing is
>>>
>>> someDoc[=E2=80=98_=E2=80=99id=E2=80=99]
>>>
>>> This just does not roll of the fingers well. Too many =E2=80=9Creach fo=
r modifier keys=E2=80=9D in a row. I would rather use
>>>
>>> someDoc._id
>>>
>>> Googling shows that I=E2=80=99m not the first to want to do this in the=
 general sense (e.g. http://stackoverflow.com/questions/4984647/accessing-d=
ict-keys-like-an-attribute-in-python).
>>>
>>> Arguments aside of whether this should or shouldn=E2=80=99t be done, I =
want to know how I might solve this with Python. Consider it an academic pu=
rsuit.
>>>
>>> The problem I have is not how to do the AttributeDictionary subclass, t=
here are plenty of those examples. The problem is that the pymongo APIs alr=
eady return dictionaries. In a language (Smalltalk, Objective-C, Ruby) that=
 supports class extensions, that would be my first tool of choice to solve =
this problem. I=E2=80=99d just extend Dictionary to behave the way I want a=
nd be done with it. I can=E2=80=99t do that in Python though. I guess I cou=
ld make my own module that subclasses the relevant pymongo classes, and do =
super() calling implementations of all of the relevant methods, coercing th=
e return type. That is a maintenance headache though.
>>>
>>> What are my options, if any?
>>
>> You could construct the AttributeDictionary by copying the dict
>> returned from pymongo. The question then is whether the copying would
>> be too expensive or not.
>>
>> Alternately, you could just wrap the dictionaries returned by pymongo
>> in an object. Something like this should be all you need:
>>
>> class AttrDictWrapper(object):
>>    def __init__(self, the_dict):
>>        self.__dict__ =3D the_dict
>>
>>>>> d =3D AttrDictWrapper({'spam': 42, 'ham': False})
>>>>> d.spam
>> 42
>>>>> d.ham
>> False
>>
>
> Yes, that is clever. So if you wanted to minimize the amount of typing yo=
u had to do at all of your pymongo API call sites, what strategy would you =
use to keep that relatively terse?
>
> Is the following the right approach to take?
>
> class Doc(object):
>     def __init__(self, target):
>         self.__dict__ =3D target
>
> and then something like
>
> for doc in client.db.radios.find({=E2=80=99_id': {=E2=80=99$regex=E2=80=
=99: =E2=80=98^[ABC]'}}):
>     pprint(doc)
>
> changes to
>
> for doc in ((Doc(d) for d in client.db.radios.find({=E2=80=99_id': {=E2=
=80=99$regex=E2=80=99: =E2=80=98^[ABC]'}})):
>     pprint(doc)
>
> Are there other approaches? Feel free to impress me with evil abuses in t=
he interest of academic enrichment...

One possible approach, that may or may not work based on the use case,
would be to monkey patch the module. The main drawback is that if it
is used in places that do not expect the wrapper, it could well break.
Untested code:

import types
def monkey(module):
    for attr in dir(module):
        if attr.startswith('_'): # Ignore private attributes.
            continue
        object =3D getattr(module, attr)
        if not isinstance(object, types.Function): # Ignore non-functions.
            continue
        setattr(module, attr, lambda *args, **kwargs:
AttrDictWrapper(object(*args, **kwargs)))


Another option would be to create a wrapper module. This option has
the side-effect that it would be difficult to recurse into classes, as
you would have to copy the class. This would be very similar (again,
untested):
import types # Note that this may get overridden in the function,
which could cause problems.
def makeWrapper(module):
    for attr in dir(module):
        if attr.startswith('_'): # Ignore private attributes.
            continue
        object =3D getattr(module, attr)
        if not isinstance(object, types.Function): # Ignore non-functions.
            object =3D lambda *args, **kwargs:
AttrDictWrapper(object(*args, **kwargs))
        globals()[attr] =3D object


Both of these are written to (attempt) to replace all instances.
Obviously, this could be reduced to a white-list or additional checks
could be made to restrict the wrapped sets. I would be VERY weary of
actually using the first due to the noted drawback. The second is
safer, but you would want to be careful to test it for unexpected
side-effects.