"Martin v. Loewis" wrote:
Isn't there a way to accomplish the desired effect without modifying the instance? In the context of __findattr__, *we* know that we don't want to get a recursive call. Let's assume __getattr__ and __setattr__ had yet another optional parameter: infindattr, defaulting to 0. We would than have to pass a positive value in this context, which would object.c tell to not try to invoke __findattr__ again.
Who is "we" here? The Python code implementing __findattr__? How would it pass a value to __setattr__? It doesn't call __setattr__, instead it has "self.__myfoo = x"...
Ouch - right! Sorry :)
I agree that the current implementation is not thread-safe. To solve that, you'd need to associate with each instance not a single "infindattr" attribute, but a whole set of them - one per "thread of execution" (which would be a thread-id in most threading systems). Of course, that would need some cooperation from the any thread scheme (including uthreads), which would need to provide an identification for a "calling context".
Right, that is one possible way to do it. I also thought about some alternatives, but they all sound too complicated to justify them. Also I don't think this is only thread-related, since mess can happen even with an explicit coroutine jmp. Furthermore, how to deal with multiple attribute names? The function works wrong if __findattr__ tries to inspect another attribute. IMO, the state of the current interpreter changes here (or should do so), and this changed state needs to be carried down with all subsequent function calls. confused - ly chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com