[Cython] remaining open issues for 0.17

Robert Bradshaw robertwb at gmail.com
Fri Aug 10 23:00:21 CEST 2012


We have plenty of non-transitive coercions. E.g. char* <-> object <->
float. While it's technically more correct to use signed or unsigned
char, char* is pretty ubiquitous in the C world. There's also the
question of the python bytes object and array.array("c") which would
be good to support. And this would disallow any nested chars as parts
of structs (e.g. from external libraries--you could fake a signness in
your declaration but that seems ugly).

All in all, particularly in light of interfacing with external code, I
think disallowing char is overly strict.

On Fri, Aug 10, 2012 at 1:38 PM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> I agree. Non-transitive type comparisons seems like very fishy business (it
> will be *very* surprising to whoever runs across it); I think there's a
> strong case for just breaking backwards compatability:
>
> ERROR: 'char' is illegal as a buffer dtype due to being underspecified in
> the C standard, please use 'signed char' or 'unsigned char'.
>
> (Myself I always use uint8_t or int8_t rather than char...)
>
> Dag
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> "Bradley M. Froehle" <brad.froehle at gmail.com> wrote:
>>
>> I think again this is an instance of the tests being incorrect, rather
>> than the code.  The failing numpy_tests are all cases where we instantiate a
>> buffer of type 'b' (== 'signed char') but then try to use it as if it was a
>> 'char'.
>>
>> The fix, of course is to just replace most instances of 'char' with
>> 'signed char' in numpy_test.pyx:
>> https://github.com/bfroehle/cython/compare/char-buffers
>>
>> In some sense NumPy does have a notion of 'char', namely a 1 character
>> string.
>>
>> The only worry here, of course, is whether this change will painfully
>> break existing code…
>>
>> -Brad
>>
>> Actually, this fix breaks numpy_test, and I'm not sure how to fix it
>> given that numpy has no notion of a "possibly signed char" (unless we
>> disallow using char/char* with numpy altogether, which is much more
>> extreme, or don't enforce that signs match for char, which is likely
>> more invasive). Ugh.
>>
>>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>


More information about the cython-devel mailing list