Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> How should the following be handled:
> f = "parrot".index
The CPython code is:
1 0 LOAD_CONST 0 ('parrot')
3 LOAD_ATTR 0 (index)
6 STORE_NAME 1 (f)
The interesting thing is hidden in LOAD_ATTR. It seems that it creates a
call stub for the given (object, method) pair.
> ...
> print f("r")
That looks like and is a plain function call (BTW it's not covered by
your call_method proposal). The "f" object (the method call stub) has to
shift up call arguments and place the object as the first argument.
>> 2) WRT the proposed VTABLE_call_method()
>>
>> This just moves the burden of doing a method call down to all classes
>> and doesn't really fix anything. 1) is not python-specific. Moving the
>> code into language-specific PMCs hinders interoperbility and causes
>> unneeded code duplication.
> I've learned to expect such a predictable response. The exact same
> number of lines of code, and the exact same external behavior somehow
> magically hinders interoperability and causes unneeded code duplication.
What is unclear about: "This just moves the burden of doing a method
call down to all classes and doesn't really fix anything."?
> Whatever.
Again: the problem is *not* python-specific.
> - Sam Ruby
leo
