We've made class.function return a function, but the unbound method machinery
is still alive. For example, you can still create unbound methods with
new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
that refers to unbound methods.
Should this go too?
Georg
--
Thus s
Georg Brandl wrote:
> We've made class.function return a function, but the unbound method machinery
> is still alive. For example, you can still create unbound methods with
> new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
> that refers to unbound methods.
>
> Should
Christian Heimes wrote:
> I'm +1 in removing the code, too. I haven't touched the code yet in the
> case we might need it in the interim period.
I've created a patch and I'm running the test suite now.
Christian
___
Python-3000 mailing list
Python-3000@
Georg Brandl wrote:
> We've made class.function return a function, but the unbound method machinery
> is still alive. For example, you can still create unbound methods with
> new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
> that refers to unbound methods.
Removing u
Christian Heimes wrote:
> class Example:
>pass
>
> Example.id = new.instancemethod(id, None, Example)
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
met
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".
Skip
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/
[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 other develope
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
On Nov 25, 2007 2:39 PM, Christian Heimes <[EMAIL PROTECTED]> 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
> >
