[Pyrex] Regression in 0.9.6.3 when raising an exception in __len__

[Robert Bradshaw]

On Nov 16, 2007, at 12:22 PM, John Arbash Meinel wrote:

> I did work out a patch which fixes this. It seems that it was the  
> Py_ssize_t
> code. Since it changes the Signature of the len() function.
>
> This attached patch seems to fix it. I don't really like  
> introducing a two
> character signature, considering all others have a single character.
>
> The other possibility would be a simpler diff:
>
> - --- TypeSlots.py        2007-10-05 10:18:32.000000000 +0100
> +++ TypeSlots.py        2007-11-16 20:17:32.000000000 +0000
> @@ -56,6 +56,7 @@
>          'i': "-1",
>          'l': "-1",
>          'r': "-1",
> +        'Z': "-1",
>      }
>
>      def __init__(self, arg_format, ret_format):
>
> I looked at other functions which return 'Z' and it was:
> readbufferproc = Signature("TZP", "Z")
>   # typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t,  
> void **);
>
> writebufferproc = Signature("TZP", "Z")
>   # typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t,  
> void **);
>
> segcountproc = Signature("TZ", "Z")
>   # typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
>
> writebufferproc = Signature("TZS", "Z")
>   # typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t,  
> char **);
>
> and while I don't know those functions very well, they didn't seem  
> like things
> that returning -1 would be valid.
>
> For now, I'm going with the attached one, because it has a smaller  
> (more
> conservative) impact.

This is the same exact fix we used for Cython as well. See http:// 
hg.cython.org/cython/rev/17ed1c797a5f

On a similar note, you might want to remark that the builtlin hash is  
declared as returning an int rather than a long as it should be. This  
will only affect you on systems where sizeof(int) != sizeof(long)  
(e.g. 64-bit linux).

> Oh, and I tried to download the hg tarball of Pyrex so I could work  
> with it
> instead of raw directories, but it seems to contain a lot of  
> ".Foo.py" files.
> I'm pretty sure this is because whatever tar program was used was  
> "Mac OS X"
> aware and was tarring up the resource forks. It would be nice if  
> those weren't
> in the normal tarball.

I don't think the presence of these extra files would inhibit your  
use of the repository--they can just be ignored.

- Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20071116/13e97713/attachment.bin