[Pyrex] cdef __init__

Sam Rushing sam-pyrex at rushing.nightmare.com
Mon Mar 26 23:36:08 UTC 2007


Greg Ewing wrote:
> Sam Rushing wrote:
>   
>> I've just noticed that if your extension class has PyObject slots in it,
>> then the new constructor will fail.
>>     
>
> Yeah, that's another reason it's not a good idea
> to bypass __new__.
>   
How about a probe for __new__() and call it in the generated
construction code before the call to __fast_init__()?

That might be a little tricky for me, I haven't figured out how to
surgically add a series of statements yet (that is, replace one node
with several, if that's even a good idea).

Right now I'm trying to figure out how to insert code into
__fast_init_() that initializes any pyobject slots to None.
I see code.put_init_to_py_none(), just trying to generate the correct
cname arg to it...

> You also need to be careful what you do if your
> class inherits from something else. If it's not
> a Pyrex-defined class, you really have no option
> but to call its __new__ method to create it,
> since you have no way of finding out all the
> things that need to be done to initialise it
> properly.
>   

Well, I've cheated on the subclass thing by only calling __fast_init__()
if the extension type is a base class.
Of course, it'd be nice to have it work for everything.  But for the
types that we're trying to speed up, they're very simple and small
objects (linked-list nodes, small data structures full of integers, etc...).

-Sam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20070326/83a17ca8/attachment.bin 


More information about the Pyrex mailing list