Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> What is unclear about: "This just moves the burden of doing a method
>> call down to all classes and doesn't really fix anything."?
> First you state "The "f" object (the method call stub) has to
> shift up call arguments and place t
Leopold Toetsch wrote:
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_ATTR0 (index)
6 STORE_NAME
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Sam Ruby <[EMAIL PROTECTED]> wrote:
>> How should the following be handled:
>>f = "parrot".index
> The CPython code is:
> 1 0 LOAD_CONST 0 ('parrot')
> 3 LOAD_ATTR0 (index)
> 6
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_ATTR0 (index)
6 STORE_NAME 1 (f
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Ramblings on creating a new VTABLE_call_method "slot" to help with
implementing Python's bound vs unbound methods:
http://www.intertwingly.net/blog/2005/01/03/Bound-Methods
1) Methods are functions, where the first parameter is the object.
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Ramblings on creating a new VTABLE_call_method "slot" to help with
> implementing Python's bound vs unbound methods:
> http://www.intertwingly.net/blog/2005/01/03/Bound-Methods
1) Methods are functions, where the first parameter is the object.
We are current
Ramblings on creating a new VTABLE_call_method "slot" to help with
implementing Python's bound vs unbound methods:
http://www.intertwingly.net/blog/2005/01/03/Bound-Methods
This is related to a previous discussion on Overloaded Operator Methods:
http://xrl.us/ekh8
- Sam Ruby
