determining context of getattr

[Robin Becker]

In article <Pine.LNX.3.96.1000821083313.19429C-100000 at mail.perspex.com>,
Tripp Lilley <tlilley at perspex.com> writes
>On Mon, 21 Aug 2000, Thomas Wouters wrote:
>
>> > can foo's __getattr__ know that whatever it returns for 'say' is going
>> > to immediately be __call__'ed?
>> 
>> Short answer: No. Long answer: No :) Very long answer: No, unless you use
>> bytecodehacks, and don't expect the code to work properly on anything but
>> the Python you wrote it on, and don't expect it to work in all situations,
>> and don't care about Pythonic code. So, in short, don't bother.
....
This is probably right, but in pythoncom this sort of thing is actually
done for some classes. When the attribute is requested a wrapped value
is returned. if it gets called the wrapper is checked to see if the
underlying attribute is a callable. I think that's how it's done, but
Mark Hammond is the expert. Obviously if the underlying is an int the
getattr would return an int not a wrapper. I don't think the call has
any effect on the getattr so can't be used at getattr time.
>
>
>> > I vaguely recall hearing something about Py3k making primitive types
>> > into real, first-class objects that I might subclass to effect this
>> > behaviour. Any truth to that recollection of mine? ie:
>> > 
>> >    class TrippInt (int):
>> >            def __call__ (self):
>> >                    return self.__value__
>> 
>> Yes, that's high on the wishlist of Py3K, though syntax may vary.
>
>Cool.
>

-- 
Robin Becker