Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Why so? Python methods don't have a notion of an object - it's just the
>> first argument passed into a function. So I don't quite understand your
>> conclusion.
> In the case of
>x.y(z)
> The caller is passing one argument. T
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
The common cases I want to optimize for are common functions being
called as common functions. And common methods being called as methods.
Yep, that's very reasonable.
The easiest way to optimize for the common methods being called as
meth
Sam Ruby <[EMAIL PROTECTED]> wrote:
> The common cases I want to optimize for are common functions being
> called as common functions. And common methods being called as methods.
Yep, that's very reasonable.
> The easiest way to optimize for the common methods being called as
> methods is if th
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
... But that doesn't
work fur user methods, especially if there is no indication that a user
function is used as a method in the first place.
def find(s, sub):
...
In Python, this is statically determinable. If
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> ... But that doesn't
>> work fur user methods, especially if there is no indication that a user
>> function is used as a method in the first place.
>>
>> def find(s, sub):
>> ...
> In Python, this is statically determinable. I
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> Not quite. It's just:
>>
>> f = getattribute Parrot_string, "find"
>>
>> nothing more. The C vtable has to do the right thing, i.e.
>> if the attribute is a callable, it has to return a bound method object.
> Exactly.
[ I've che
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
WRT functionality: for a call it has to shift up PMC arguments and
insert the object as P5, right?
At the moment, it contains this logic. My plans are to remove the
shifting and set the object into P2 / INTERP->ctx
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
[ provide Bound_Meth core PMC classes ]
> Cool. I'd likely still subclass it to provide a get_string.
Yep.
>> WRT implementation: I'd like to swap struct_val/pmc_val for all Sub
>> classes. It's just cleaner but should be almost full
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> WRT functionality: for a call it has to shift up PMC arguments and
>> insert the object as P5, right?
> At the moment, it contains this logic. My plans are to remove the
> shifting and set the object into P2 / INTERP->ctx.current_ob
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
2) by a distinct Bound_Meth PMC class derived from 1)
The latter is probably cleaner. Binding the object to the callable could
be done e.g. by the C vtable.
That's exactly how PyBoundMeth works today.
C sets the po
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> 2) by a distinct Bound_Meth PMC class derived from 1)
>>
>> The latter is probably cleaner. Binding the object to the callable could
>> be done e.g. by the C vtable.
> That's exactly how PyBoundMeth works today.
> C sets the pointer
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 5:04 PM -0500 1/18/05, Sam Ruby wrote:
f = "Parrot".find
print f("r")
Note that I referenced the method as an attribute, and then called
it as a function.
Mmm, syntax! :) Luckily it makes no difference to us at the parrot
lev
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:04 PM -0500 1/18/05, Sam Ruby wrote:
>> f = "Parrot".find
>> print f("r")
>>
>>Note that I referenced the method as an attribute, and then called
>>it as a function.
> Mmm, syntax! :) Luckily it makes no difference to us at the parrot
> level
13 matches
Mail list logo
