[Pyrex] Questions re: malloc and instance variables...

Adapted Cat a.c.junker at gmail.com
Wed Sep 27 03:40:57 UTC 2006


On 9/26/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> Adapted Cat wrote:
> > The main problem comes when I get another object of the
> > same class, e.g. for comparison or arithmetic operations.
> > I can access self.my_struct but not other.my_struct,
>
> You need type declarations. For example,
> ...
>      def __add__(x, y):
>        cdef myclass my_x
>        cdef myclass my_y


Thanks - that worked!

Note that if you're implementing a binary operator
> method such as __add__, you'll need
>
>      def __add__(myclass x, myclass y):
>        ...
>
> i.e. don't assume that the first argument is "self"
> (see the Special Methods of Extension Types pages for
> a full explanation).


Yes, I saw that note. With regard to __sub__ as I understand it
it is always the case that __sub__(one, two) should return one - two
and not two - one...even in the case where one is not "self"-like.
Please correct me if that is not the case.

I've settled on:
  cdef myclass my_x, my_y
  if not isinstance(x, myclass):
    my_x = myclass(x)
  if not isinstance(y, myclass):
    my_y = myclass(y)

This way if I can coerce it it'll work and if I can't coerce
it then the __init__ will raise the appropriate exception.


This only happens when the ctypedef is inside a
> 'cdef extern from' block. If you do it the way
> you did in your posted code, with both the
> ctypedef and the malloc declaration inside
> 'cdef extern from "stdlib.h"', you should find
>

You're right - I had been trying to get size_t from
somewhere else.


> > In the spirit of "batteries included" couldn't Pyrex just parse
> >   cdef int *c_array[len(input)]
> > and do its own memory allocation and garbage collection in the
> > generated C code?
>
> In the simplistic sense of treating it as an
> automatic variable and freeing it on exit from
> the function, this might be doable.


Yes, that's what I had in mind.
Thanks again for your help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.copyleft.no/pipermail/pyrex/attachments/20060927/3c4e98b7/attachment.html 


More information about the Pyrex mailing list