2007/11/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Am I the only person for whom test_asynchat is hanging? If it's not already
> a known issue let me know and I'll try and characterize it a bit better than
> "it hangs".
As this not happens in all the systems, it'd be great if you could
debug i
Greg Ewing wrote:
> This needs consideration. Pyrex currently makes use of
> this behaviour when defining a Python class having Pyrex
> functions as methods.
>
> However, a better solution for Pyrex would be to add
> method-binding behaviour to the C function object, so
> that C functions can be u
> [EMAIL PROTECTED] wrote:
> > Am I the only person for whom test_asynchat is hanging? If it's not already
> > a known issue let me know and I'll try and characterize it a bit better than
> > "it hangs".
>
> No, you are not alone although I've never seen a hanging async test on
> my systems. But
Christian Heimes wrote:
> Greg Ewing wrote:
>> This needs consideration. Pyrex currently makes use of
>> this behaviour when defining a Python class having Pyrex
>> functions as methods.
>>
>> However, a better solution for Pyrex would be to add
>> method-binding behaviour to the C function object,
On Nov 26, 2007 2:53 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Christian Heimes wrote:
> > Greg Ewing wrote:
> >> This needs consideration. Pyrex currently makes use of
> >> this behaviour when defining a Python class having Pyrex
> >> functions as methods.
> >>
> >> However, a better solution
Nick Coghlan wrote:
> Interestly, I just discovered that method descriptors for builtins don't
> define im_class, im_self or im_func. I never knew that - I thought they
> had the same interface as instance methods.
A builtin method descriptor is the C equivalent of a
function object, not an inst
On Nov 26, 2007 3:49 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> > Interestly, I just discovered that method descriptors for builtins don't
> > define im_class, im_self or im_func. I never knew that - I thought they
> > had the same interface as instance methods.
>
> A builtin
Guido van Rossum wrote:
> They have that too. See:
>
f = list.append
g = f.__get__(a)
g
>
>
Hmmm. It seems that C method objects are more
like an unbound method object that's pre-bound to a
particular class.
I'm concerned with built-in function objects that
are *not* methods of any
