On 10/09/2010 02:04 PM, Stefan Behnel wrote:
> Robert Bradshaw, 09.10.2010 13:21:
>
>> On Fri, Oct 8, 2010 at 11:21 PM, Stefan Behnel wrote:
>>
>>> So, for char* values, "s1 == s2" should translate into
>>>
>>> (s1 == s2) || (
>>> (s1 != NULL)&& (s2 != NULL)&& (strcmp(s1, s2) == 0))
>>>
>>> Note that this allows both pointers to be NULL in the success case. I think
>>> it makes sense to include this.
>>>
>>> This change certainly introduces new corner cases, though, as "ptr == ptr"
>>> means "ptr is ptr" for everything else. So this will surprise at least some
>>> users and also break existing code. But I think it's at least mostly obvious
>>> to the average Python developer what the right fix is.
>>>
>> +0.5 to this. If not, it would at least be worth a warning.
>>
> Thinking about this some more, "==" isn't the only operator where this
> makes sense. Basically, all comparison operators (also<,<=,>,>=) should
> potentially behave the same on bytes objects and char* objects. However,
> for everything but "==", there isn't a simple operator replacement like
> "is" that explicitly compares the pointers if the need arises, but a
> pointer cast to<void*> should do the trick.
>
I agree that < and == should be consistent. But < is used for pointer
comparison as well in C...
for (i = start; i < end; ++i) ...
In such situations, one can normally use != ("is not"), but it is not
completely unimaginable that < on pointers can have a use in some algorithm.
I just suggest that this is something to be aware of (put in release
notes etc.), and suggest
<size_t>i < <size_t>end
as an alternative if one really needs this.
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
