restobjects like Room and User are great, and it's great to be able to access their keys as attributes like "room_object.name". Often they have nested data structures as values, and it would be nice to use attribute access throughout the data structure instead of just on the top level. And it would be nice for optional keys, which may be omitted from hipchat JSON, to return None rather than raise AttributeError.
If you add a class like AttributeDict:
class AttributeDict(dict):
def __getattr__(self, name):
# from is a common property name in HipChat json, but it's a Python keyword.
if name == 'from_':
name = 'from'
return self.get(name, None)
and then change _object_hook to do return AttributeDict(obj) in the else: clause, it works great.
Dictionary-style access is preserved, so we're not losing any features here. Nested dict values, if processed by _object_hook, will already be AttributeDict objects, so I don't think there's any need for AttributeDict to wrap a dict value in an AttributeDict on the fly. But perhaps we would need to do this in an override of getitem and setitem.
restobjects like Room and User are great, and it's great to be able to access their keys as attributes like "room_object.name". Often they have nested data structures as values, and it would be nice to use attribute access throughout the data structure instead of just on the top level. And it would be nice for optional keys, which may be omitted from hipchat JSON, to return None rather than raise AttributeError.
If you add a class like AttributeDict:
and then change _object_hook to do
return AttributeDict(obj)in theelse:clause, it works great.Dictionary-style access is preserved, so we're not losing any features here. Nested dict values, if processed by _object_hook, will already be AttributeDict objects, so I don't think there's any need for AttributeDict to wrap a dict value in an AttributeDict on the fly. But perhaps we would need to do this in an override of getitem and setitem.