By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,486 Members | 1,199 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,486 IT Pros & Developers. It's quick & easy.

automatic accessors to a member var dict elements?

P: n/a
If I have the following class:

class MyClass:
def __init__(self):
m_dict = {}
m_dict['one'] = 1
m_dict['two'] = 2
m_dict['three'] = 3

Is there anyway to generate automatic accessors to the elements of the dict?
For example, so I could say:

obj = MyClass()
obj.one # returns obj.my_dict['one']
obj.one = 'won' # same as obj.my_dict['one'] = 'won'

By automatic, I mean so I don't have to write out each method by hand and
also dynamic, meaning if m_dict changes during runtime, the accessors are
automatically updated to reflect the change.

Thanks for the help.

Jul 18 '05 #1
Share this Question
Share on Google+
12 Replies

P: n/a
Christopher J. Bottaro wrote:
If I have the following class:

class MyClass:
def __init__(self):
m_dict = {}
m_dict['one'] = 1
m_dict['two'] = 2
m_dict['three'] = 3

First of all, you need to hold onto a copy of that dict if you want to
be able to do anything with it. You're creating m_dict as a local
variable inside of __init__(), which goes out of scope when __init__()
ends, and is then garbage-collected. To get it to stay around, store it
as an attribute of 'self' --

self.m_dict = {}
self.m_dict['one'] = 1
self.m_dict['two'] = 2

and so on.
Is there anyway to generate automatic accessors to the elements of the dict?
For example, so I could say:

obj = MyClass()
obj.one # returns obj.my_dict['one']
obj.one = 'won' # same as obj.my_dict['one'] = 'won'


If you want to be able to access these items as if they were plain
attributes of your class instance, is there any reason why you're not
just creating them as attributes?

class MyClass:
def __init___(self):
self.one = 1

obj = MyClass()
obj.one # --> 1
obj.one = 'won'

If you really do need to maintain the dict separately, then you can use
__getattr__() and __setattr__() to redirect accesses of nonexistent
attributes into operations on your contained dict, something like this
(untested):

class MyClass(object): # ensure a new-style class
def __init__(self):
self.m_dict = {'one':1, 'two':2, 'three':3}
def __getattr__(self, attr):
value = self.m_dict.get(attr, None)
if value is None:
raise AttributeError(attr)
return value
def __setattr__(self, attr, value):
self.m_dict[attr] = value

I'm using a new-style class to take advantage of improvements in
attribute lookup. For this class, __getattr__()/__setattr__() will only
be called if attr isn't found through the normal attribute resolution
rules.

One problem with the way I'm doing things here is that, if you set a
dict item to a value of None, the object will raise an AttributeError
when trying to access that item. This really ought to use a safer
sentinel value. (Check for a recent thread here in c.l.py about
sentinel values and the use of object() as one.)

It might be possible to use the mechanism you seem to want
(automatically generating individual get/set methods, attaching them to
the instance, creating a new property from the getter/setter), but that
would involve significantly more complexity and magic, and would gain
you very little (if anything).

Jeff Shannon
Technician/Programmer
Credit International
Jul 18 '05 #2

P: n/a
On Thu, 14 Oct 2004 17:56:09 -0700, Jeff Shannon <je**@ccvcorp.com> wrote:
[...]

If you really do need to maintain the dict separately, then you can use
__getattr__() and __setattr__() to redirect accesses of nonexistent
attributes into operations on your contained dict, something like this
(untested):

class MyClass(object): # ensure a new-style class
def __init__(self):
self.m_dict = {'one':1, 'two':2, 'three':3}
def __getattr__(self, attr): try: return self.m_dict[attr]
except KeyError: raise AttributeError(attr)
value = self.m_dict.get(attr, None)
if value is None:
raise AttributeError(attr)
return value
def __setattr__(self, attr, value):
self.m_dict[attr] = value

I'm using a new-style class to take advantage of improvements in
attribute lookup. For this class, __getattr__()/__setattr__() will only
be called if attr isn't found through the normal attribute resolution
rules.

One problem with the way I'm doing things here is that, if you set a
dict item to a value of None, the object will raise an AttributeError
when trying to access that item. This really ought to use a safer
sentinel value. (Check for a recent thread here in c.l.py about
sentinel values and the use of object() as one.)

Why not (untested) avoid the default sentinel and just translate
a key error to an attribute error as above?

Regards,
Bengt Richter
Jul 18 '05 #3

P: n/a
Christopher J. Bottaro <cj*******@alumni.cs.utexas.edu> wrote:
If I have the following class:

class MyClass:
def __init__(self):
m_dict = {}
m_dict['one'] = 1
m_dict['two'] = 2
m_dict['three'] = 3

Is there anyway to generate automatic accessors to the elements of the dict?
For example, so I could say:

obj = MyClass()
obj.one # returns obj.my_dict['one']
obj.one = 'won' # same as obj.my_dict['one'] = 'won'

By automatic, I mean so I don't have to write out each method by hand and
also dynamic, meaning if m_dict changes during runtime, the accessors are
automatically updated to reflect the change.


Here is an old style class way of doing it. I think there might be a
better way with new style classes but I'm not up to speed on them!

Note care taken to set m_dict as self.__dict__["m_dict"] rather than
self.m_dict otherwise the __setattr__ will recurse! You can put a
special case in __setattr__ if you prefer.

class MyClass:
def __init__(self):
self.__dict__["m_dict"] = {}
self.m_dict['one'] = 1
self.m_dict['two'] = 2
self.m_dict['three'] = 3
def __getattr__(self, name):
return self.m_dict[name]
def __setattr__(self, name, value):
self.m_dict[name] = value
obj = MyClass()
print obj.one 1 obj.one = 'won'
print obj.one

won

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick
Jul 18 '05 #4

P: n/a
Jeff Shannon <je**@ccvcorp.com> wrote:
class MyClass(object): # ensure a new-style class
def __init__(self):
self.m_dict = {'one':1, 'two':2, 'three':3}
def __getattr__(self, attr):
value = self.m_dict.get(attr, None)
if value is None:
raise AttributeError(attr)
return value
def __setattr__(self, attr, value):
self.m_dict[attr] = value

I'm using a new-style class to take advantage of improvements in
attribute lookup. For this class, __getattr__()/__setattr__() will only
be called if attr isn't found through the normal attribute resolution
rules.


It doesn't!
class MyClass(object): # ensure a new-style class .... def __init__(self):
.... self.m_dict = {'one':1, 'two':2, 'three':3}
.... def __getattr__(self, attr):
.... value = self.m_dict.get(attr, None)
.... if value is None:
.... raise AttributeError(attr)
.... return value
.... def __setattr__(self, attr, value):
.... self.m_dict[attr] = value
.... obj = MyClass()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __init__
File "<stdin>", line 10, in __setattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
[snip]
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
RuntimeError: maximum recursion depth exceeded

I know there is something different about new style classes in this
area, but thats not it!

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick
Jul 18 '05 #5

P: n/a
On 15 Oct 2004 08:30:02 GMT, Nick Craig-Wood <ni**@craig-wood.com> wrote:
Jeff Shannon <je**@ccvcorp.com> wrote:
class MyClass(object): # ensure a new-style class
def __init__(self):
self.m_dict = {'one':1, 'two':2, 'three':3}
def __getattr__(self, attr):
value = self.m_dict.get(attr, None)
if value is None:
raise AttributeError(attr)
return value
def __setattr__(self, attr, value):
self.m_dict[attr] = value

I'm using a new-style class to take advantage of improvements in
attribute lookup. For this class, __getattr__()/__setattr__() will only
be called if attr isn't found through the normal attribute resolution
rules.
It doesn't!

Oops, I missed that too, as I was focusing on the if-value-is-None logic,
class MyClass(object): # ensure a new-style class... def __init__(self):
... self.m_dict = {'one':1, 'two':2, 'three':3}
... def __getattr__(self, attr):
... value = self.m_dict.get(attr, None)
... if value is None:
... raise AttributeError(attr)
... return value
... def __setattr__(self, attr, value):
... self.m_dict[attr] = value
Maybe:
class MyClass(object): # ensure a new-style class ... def __init__(self):
... object.__setattr__(self, 'm_dict', {'one':1, 'two':2, 'three':3})
... def __getattr__(self, attr):
... if attr == 'm_dict': return object.__getattribute__(self, attr)
... try: return self.m_dict[attr]
... except KeyError: raise AttributeError(attr)
... def __setattr__(self, attr, value):
... self.m_dict[attr] = value
... mc = MyClass()
mc.two 2 mc.three 3 mc.four Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 7, in __getattr__
AttributeError: four mc.four = 4
mc.four 4 mc.m_dict
{'four': 4, 'three': 3, 'two': 2, 'one': 1}
... obj = MyClass()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __init__
File "<stdin>", line 10, in __setattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
[snip]
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
RuntimeError: maximum recursion depth exceeded

I know there is something different about new style classes in this
area, but thats not it!

You can make self.m_dict raise an attribute error too, but then you can't
write your methods with self.m_dict, since that will trigger recursion.
object.__getattribute__(self, 'm_dict') instead.

Bottom line, though: Why use self.m_dict when you get self.__dict__ for free,
along with attribute access? I.e., self.x is effectively self.__dict__['x']

IOW, self.__dict__ works like you went to all that trouble to make self.m_dict work,
unless your class defines class variables or properties that you want to shadow under
all circumstances.

Regards,
Bengt Richter
Jul 18 '05 #6

P: n/a
Nick Craig-Wood wrote:
class MyClass(object): # ensure a new-style class

... def __init__(self):
... self.m_dict = {'one':1, 'two':2, 'three':3}
... def __getattr__(self, attr):
... value = self.m_dict.get(attr, None)
... if value is None:
... raise AttributeError(attr)
... return value
... def __setattr__(self, attr, value):
... self.m_dict[attr] = value
...

obj = MyClass()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 3, in __init__
File "<stdin>", line 10, in __setattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
[snip]
File "<stdin>", line 5, in __getattr__
File "<stdin>", line 5, in __getattr__
RuntimeError: maximum recursion depth exceeded

I know there is something different about new style classes in this
area, but thats not it!


Hmmm... Actually, I think that the problem here is that during
__init__(), we're trying to set the attribute m_dict, which doesn't
exist yet, so it tries to look in self.m_dict to find it...

Modifying __init__() so to use self.__dict__['m_dict'] instead of
self.m_dict will likely fix this. (But I still haven't tested it...)

Jeff Shannon
Technician/Programmer
Credit International
Jul 18 '05 #7

P: n/a
Bengt Richter wrote:
On Thu, 14 Oct 2004 17:56:09 -0700, Jeff Shannon <je**@ccvcorp.com> wrote:
[...]

One problem with the way I'm doing things here is that, if you set a
dict item to a value of None, the object will raise an AttributeError
when trying to access that item. This really ought to use a safer
sentinel value. (Check for a recent thread here in c.l.py about
sentinel values and the use of object() as one.)

Why not (untested) avoid the default sentinel and just translate
a key error to an attribute error as above?


Good point -- that makes this safer, cleaner, and more Pythonic. :)

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #8

P: n/a
Jeff Shannon wrote:
Nick Craig-Wood wrote:
I know there is something different about new style classes in this
area, but thats not it!

Hmmm... Actually, I think that the problem here is that during
__init__(), we're trying to set the attribute m_dict, which doesn't
exist yet, so it tries to look in self.m_dict to find it...

Modifying __init__() so to use self.__dict__['m_dict'] instead of
self.m_dict will likely fix this. (But I still haven't tested it...)

And, because I'm slacking off on my real work:
class MyClass(object): .... def __init__(self):
.... self.__dict__['m_dict'] = {'one':1, 'two':2, 'three':3}
.... def __getattr__(self, attr):
.... try:
.... value = self.m_dict[attr]
.... except KeyError:
.... raise AttributeError(attr)
.... return value
.... def __setattr__(self, attr, value):
.... self.m_dict[attr] = value
....
obj = MyClass()
obj.one 1 obj.two 2 obj.one = 'won'
obj.one 'won' obj.four = 4
obj.m_dict {'four': 4, 'three': 3, 'two': 2, 'one': 'won'} obj.five Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 8, in __getattr__
AttributeError: five
Hm, that error message is a bit weak. If we replace the 'raise
AttributeError(attr)' with '''raise AttributeError("%s instance has no
attribute '%s'" % (self.__class__.__name__, attr))''', we'll get an
error message that's much more in line with a 'normal' AttributeError.
obj.five Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "<interactive input>", line 8, in __getattr__
AttributeError: MyClass instance has no attribute 'five'


Jeff Shannon
Technician/Programmer
Credit International
Jul 18 '05 #9

P: n/a
Jeff Shannon <je**@ccvcorp.com> wrote:
...
__getattr__() and __setattr__() to redirect accesses of nonexistent
attributes into operations on your contained dict, something like this
(untested):

class MyClass(object): # ensure a new-style class
def __init__(self):
self.m_dict = {'one':1, 'two':2, 'three':3}
def __getattr__(self, attr):
value = self.m_dict.get(attr, None)
if value is None:
raise AttributeError(attr)
return value
def __setattr__(self, attr, value):
self.m_dict[attr] = value

I'm using a new-style class to take advantage of improvements in
attribute lookup. For this class, __getattr__()/__setattr__() will only
be called if attr isn't found through the normal attribute resolution
Yes for __getattr__, but no for __setattr__ -- in both cases, just like
in classic classes. When in __init__ you try to set attr m_dict (and in
this case it wouldn't even make much sense to say it's "found through
the normal attribute resolution" -- it's not there yet at that time, so
it couldn't be found), this invokes __setattr__, which goes boom
(because m_dict ain't set yet). If you needed that __setattr__, your
__init__ should assign self.__dict__['m_dict'] instead. But the OP
didn't ask for that __setattr__ anyway, so I'd remove it instead.
rules.

One problem with the way I'm doing things here is that, if you set a
dict item to a value of None, the object will raise an AttributeError
when trying to access that item. This really ought to use a safer
sentinel value. (Check for a recent thread here in c.l.py about
sentinel values and the use of object() as one.)
A better solution than a sentinel, in this case:

def __getattr__(self, attr):
try: return self.m_dict[attr]
except KeyError: raise AttributeError, attr

It might be possible to use the mechanism you seem to want
(automatically generating individual get/set methods, attaching them to
the instance, creating a new property from the getter/setter), but that
would involve significantly more complexity and magic, and would gain
you very little (if anything).


Complete agreement here -- __getattr__ is clearly the way to go for this
specific requirement.
Alex
Jul 18 '05 #10

P: n/a
Nick Craig-Wood <ni**@craig-wood.com> wrote in message news:<sl*****************@irishsea.home.craig-wood.com>...
Christopher J. Bottaro <cj*******@alumni.cs.utexas.edu> wrote:
If I have the following class:

class MyClass:
def __init__(self):
m_dict = {}
m_dict['one'] = 1
m_dict['two'] = 2
m_dict['three'] = 3

Is there anyway to generate automatic accessors to the elements of the dict?
For example, so I could say:

obj = MyClass()
obj.one # returns obj.my_dict['one']
obj.one = 'won' # same as obj.my_dict['one'] = 'won'

By automatic, I mean so I don't have to write out each method by hand and
also dynamic, meaning if m_dict changes during runtime, the accessors are
automatically updated to reflect the change.


Here is an old style class way of doing it. I think there might be a
better way with new style classes but I'm not up to speed on them!

Note care taken to set m_dict as self.__dict__["m_dict"] rather than
self.m_dict otherwise the __setattr__ will recurse! You can put a
special case in __setattr__ if you prefer.

class MyClass:
def __init__(self):
self.__dict__["m_dict"] = {}
self.m_dict['one'] = 1
self.m_dict['two'] = 2
self.m_dict['three'] = 3
def __getattr__(self, name):
return self.m_dict[name]
def __setattr__(self, name, value):
self.m_dict[name] = value
obj = MyClass()
print obj.one 1 obj.one = 'won'
print obj.one

won


To me, it appears the Christopher is simply looking for a way to
get/set members of a dictionary using a different syntax.

That being the case, why not create a pythonic solution like the one
above using new style classes, as we can derive directly from the dict
type?

In this case, we will just forward the __getattr__ and __setattr__
calls to __getitem__ and __setitem__, respectively.

Here is the equivalent solution:

class MyClass (dict): #New style class derived from dict
type

#Use same get/set syntax desired during construction
def __init__(self):
self.one = 1
self.two = 2
self.three = 3

#Get/set syntax changed with simple forwarding functions
def __getattr__(self, key):
return self.__getitem__(key)
def __setattr__(self, key, value):
self.__setitem__(key, value)
Isn't this the type of thing that Guido van Rossum envisioned in
trying to unify types and classes?

Michael Loritsch
Jul 18 '05 #11

P: n/a
Jeff Shannon <je**@ccvcorp.com> wrote:
...
>>> class MyClass(object):

... def __init__(self):
... self.__dict__['m_dict'] = {'one':1, 'two':2, 'three':3}


Incidentally, I suspect

object.__setattr__(self, 'm_dict', dict(one=1, two=2, three=3))

is preferable to working on self.__dict__ overtly, when self's class is
newstyle, at least (though I think it might work with classic classes
too). It should come down to the same effect in normal cases, but might
work better if (e.g.) there's a __slots__ = ['m_dict_'] somewhere;-).
Alex
Jul 18 '05 #12

P: n/a
Michael Loritsch <lo******@gmail.com> wrote:
...
class MyClass (dict): #New style class derived from dict
type

#Use same get/set syntax desired during construction
def __init__(self):
self.one = 1
self.two = 2
self.three = 3

#Get/set syntax changed with simple forwarding functions
def __getattr__(self, key):
return self.__getitem__(key)
def __setattr__(self, key, value):
self.__setitem__(key, value)

Isn't this the type of thing that Guido van Rossum envisioned in
trying to unify types and classes?


Any deliberate seeding of confusion between items and attributes will
eventually cause grief, IMHO. Specifically, I'd find it unnerving that
after foo=MyClass(), some foo[x]=y for runtime read/computed values of x
and y may make all kinds of methods unaccessible on foo -- say
foo.keys(), foo.pop(), and so on. Basically, any such foo would need to
be only ever accessed by implied lookup of special methods (working on
the class, and not the instance, fortunately), and never by any name
lookup of a method on the instance itself. Looks like a deliberate
attempt to put oneself in a fragile, error-prone situation. Maybe I'm
just a pessimist!
Alex
Jul 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.