Christian Heimes schrieb:
> Thomas Heller wrote:
>> Ok, so one has to write an extension to access or expose it.
>>
>> Oh, wait - there's ctypes:
>
> I wrote the type to help the Pyrex and Cython developers to port their
> software to 3.0. I planed to expose the type as
> __builtin__.instanceme
Thomas Heller wrote:
Ok, so one has to write an extension to access or expose it.
Oh, wait - there's ctypes:
I wrote the type to help the Pyrex and Cython developers to port their
software to 3.0. I planed to expose the type as
__builtin__.instancemethod but forgot it. Maybe we can convince
Terry Reedy schrieb:
> Thomas Heller wrote:
>> Christian Heimes schrieb:
>>> I've written PyInstanceMethod_Type for this use case. It's not (yet)
>>> available for Python code.>> Oh, wait - there's ctypes:
>>
>> Python 3.0rc1 (r30rc1:66507, Sep 18 2008, 14:47:08) [MSC v.1500 32 bit
>> (Intel)] o
Thomas Heller wrote:
Christian Heimes schrieb:
Thomas Heller wrote:
but this is very ugly, imo. Is there another way?
The raw_func instances that I have are not descriptors (they
do not implement a __get__() method...)
I've written PyInstanceMethod_Type for this use case. It's not (yet)
avail
Christian Heimes schrieb:
> Thomas Heller wrote:
>> but this is very ugly, imo. Is there another way?
>> The raw_func instances that I have are not descriptors (they
>> do not implement a __get__() method...)
>
> I've written PyInstanceMethod_Type for this use case. It's not (yet)
> available fo
Thomas Heller a écrit :
I'm currently using code like this to create unbound methods
from functions and stick them into classes:
method = new.instancemethod(raw_func, None, cls)
setattr(cls, name, method)
setattr(cls, name, func) would work better - given that either
isins
Thomas Heller wrote:
but this is very ugly, imo. Is there another way?
The raw_func instances that I have are not descriptors (they
do not implement a __get__() method...)
I've written PyInstanceMethod_Type for this use case. It's not (yet)
available for Python code. Barry hasn't decided whet
I'm currently using code like this to create unbound methods
from functions and stick them into classes:
method = new.instancemethod(raw_func, None, cls)
setattr(cls, name, method)
Ok, python 2.6, run with the -3 flag, gives a warning that the new
module is going away in python 3.0, s
In article <[EMAIL PROTECTED]>,
"Michele Simionato" <[EMAIL PROTECTED]> wrote:
> Duncan Booth wrote:
> > Ron Garret <[EMAIL PROTECTED]> wrote:
> >
> > > I want to say:
> > >
> > > trace(c1.m1)
> > >
> > > and have c1.m1 be replaced with a wrapper that prints debugging info
> > > before actually c
In article <[EMAIL PROTECTED]>,
Kent Johnson <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
> > The reason I want to do this is that I want to implement a trace
> > facility that traces only specific class methods. I want to say:
> >
> > trace(c1.m1)
> >
> > and have c1.m1 be replaced with a
Ron Garret wrote:
> The reason I want to do this is that I want to implement a trace
> facility that traces only specific class methods. I want to say:
>
> trace(c1.m1)
>
> and have c1.m1 be replaced with a wrapper that prints debugging info
> before actually calling the old value of m1. The
Ron Garret wrote:
> The reason I want to do this is that I want to implement a trace
> facility that traces only specific class methods. I want to say:
>
> trace(c1.m1)
>
> and have c1.m1 be replaced with a wrapper that prints debugging info
> before actually calling the old value of m1. The
Duncan Booth wrote:
> Ron Garret <[EMAIL PROTECTED]> wrote:
>
> > I want to say:
> >
> > trace(c1.m1)
> >
> > and have c1.m1 be replaced with a wrapper that prints debugging info
> > before actually calling the old value of m1. The reason I want that
> > to be an instance of a callable class inste
Ron Garret <[EMAIL PROTECTED]> wrote:
> I want to say:
>
> trace(c1.m1)
>
> and have c1.m1 be replaced with a wrapper that prints debugging info
> before actually calling the old value of m1. The reason I want that
> to be an instance of a callable class instead of a function is that I
> need
If I do this:
def f(self): print self
class c1: pass
setattr(c1, 'm1', f)
Then f is automagically transmogrified into the appropriate sort of
method depending on how it is used:
>>> c1.m1
>>> c1().m1
>
>>> c1().m1()
<__main__.c1 instance at 0x51ec60>
Note that m1 gets passed a self argument
[EMAIL PROTECTED] wrote:
> I wrote a small class today at work playing with sockets in command
> line windows. When attempting to call the handle function, I get a
> TypeError. "Unbound method handle() must be called with connection
> instance as first argument (got nothing instead). Any suggest
In <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I wrote a small class today at work playing with sockets in command
> line windows. When attempting to call the handle function, I get a
> TypeError. "Unbound method handle() must be called with connection
> instance as first argument (got nothin
I wrote a small class today at work playing with sockets in command
line windows. When attempting to call the handle function, I get a
TypeError. "Unbound method handle() must be called with connection
instance as first argument (got nothing instead). Any suggestions
would be greatly appreciated.
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
Something important that came up in my response to Marc-Andre:
What about C method implementations which are relying on this typecheck and
assuming that '
Andrew Koenig wrote:
duck typing?
That's the Australian pronunciation of "duct taping".
More Kiwi, I'm thinking ;)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.s
20 matches
Mail list logo
