Newbie question about __getattr__ and __setattr__

Felix Thibault felixt at dicksonstreet.com
Tue Oct 12 01:40:45 EDT 1999


On Sat, 09 Oct 1999 01:24:38 -0400, Eric Jacobs <x at x.x> wrote:
> 
> A couple of things going on here. First, you want to deal with
> __getitem__ and __setitem__ -- those deal with the [] subscript
> operator -- rather than __getattr__ and __setattr__ that deal
> with the . attribute operator.
> 
> The syntax that you want to write the assignment is supported
> by the interpreter by default; you don't need to change 
> anything for that. The only catch is that the first two layers
> of dictionaries need to exist beforehand. So if you had
> 
>    i = {1: {2: {}}}
>    i[1][2][3] = 4
>  
> then i would be {1: {2: {3: 4}}} as you'd expect.
[snip]
> So if you want that assignment to work when the sub-
> dictionaries aren't predefined, you can have your
> __getitem__ always create new dictionaries. That's
> fairly simple, just add a method:
> 
> 	def __getitem__(s, k):
> 		if k not in s.keys():
> 			s[k] = Nester({})
> 		return s.data[k]
> 
> Be sure to mention the s.data[k] and not just s[k], or
> you'll end up in an infinite loop. Here, if the key is not
> found, we generate a new custom Nester object, so that it
> works for more than one level. In fact, because there's no
> limit placed here, this will work for any number of nested 
> levels:
> i['a']['b']['c']['d']['e'][...
> 
> The disadvantage is that reading a missing value will
> result in a new empty dictionary being created and returned!
> So unless you want to be really careful and write a clean-
> up routine which can handle this, you're going to have a
> bunch of extra empty dictionaries floating around. You will
> also never get KeyError with this simple method.

So I would need to, for example, make a function that checks
the value of a key and deletes it and raises a KeyError if it's {}, and
then call that function after every read ?



> 
> It seems that the parser would know whether a compound
> construct like i[1][2][3] is going to be an l-value or
> r-value, and could emit a different code that could be
> passed on to __getitem__ (BINARY_SUBSCRL, maybe, means
> that this expression is intended to be an l-value.) It
> would be difficult to make this change in a compatible
> way. It's a thought..
> 
> Hope this helps.
> 
> 

Thanks!




More information about the Python-list mailing list