automatic accessors to a member var dict elements?

  • Thread starter Christopher J. Bottaro
  • Start date
C

Christopher J. Bottaro

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.
 
J

Jeff Shannon

Christopher said:
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
 
B

Bengt Richter

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
 
N

Nick Craig-Wood

Christopher J. Bottaro said:
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
won
 
N

Nick Craig-Wood

Jeff Shannon said:
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!
.... 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
.... 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!
 
B

Bengt Richter

Jeff Shannon said:
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,
... 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:
... 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
... Traceback (most recent call last):
File "<stdin>", line 1, in ?
{'four': 4, 'three': 3, 'two': 2, 'one': 1}
... 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
 
J

Jeff Shannon

Nick said:
... 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
...

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
 
J

Jeff Shannon

Bengt said:
[...]

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
 
J

Jeff Shannon

Jeff said:
Nick said:
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:
.... 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
.... Traceback (most recent call last):
File "<interactive input>", line 1, in ?

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.
Traceback (most recent call last):
File "<interactive input>", line 1, in ?

Jeff Shannon
Technician/Programmer
Credit International
 
A

Alex Martelli

Jeff Shannon said:
__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
 
M

Michael Loritsch

Nick Craig-Wood said:
Christopher J. Bottaro said:
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
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
 
A

Alex Martelli

Jeff Shannon said:
... 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
 
A

Alex Martelli

Michael Loritsch said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,576
Members
45,054
Latest member
LucyCarper

Latest Threads

Top