On Sun, Aug 30, 2015 at 9:09 PM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
>
> There are three ways of fixing this that I see:
>
>1. Arbitrarily choose a value to set the return to. This is equivalent
>to choosing a default return for `cmp` for comparisons. This preserves
>
On Mon, Aug 31, 2015 at 10:31 AM, Antoine Pitrou wrote:
> On Mon, 31 Aug 2015 10:23:10 -0700
> Stephan Hoyer wrote:
>>
>> My inclination is that return NaN would be the appropriate choice. It's
>> certainly consistent with the behavior for float dtypes -- my expectation
>> for object dtype behavi
On Mo, 2015-08-31 at 10:23 -0700, Stephan Hoyer wrote:
> On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg
> wrote:
> That would be my gut feeling as well. Returning `NaN` could
> also make
>
> sense, but I guess we run into problems since we do not know
> th
On Mon, 31 Aug 2015 10:23:10 -0700
Stephan Hoyer wrote:
>
> My inclination is that return NaN would be the appropriate choice. It's
> certainly consistent with the behavior for float dtypes -- my expectation
> for object dtype behavior is that it works exactly like applying the
> np.sign ufunc to
On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg
wrote:
> That would be my gut feeling as well. Returning `NaN` could also make
> sense, but I guess we run into problems since we do not know the input
> type. So `None` seems like the only option here I can think of right
> now.
>
My inclination i
On So, 2015-08-30 at 21:09 -0700, Jaime Fernández del Río wrote:
> There's been some work going on recently on Py2 vs Py3 object
> comparisons. If you want all the background, see gh-6265 and follow
> the links there.
>
>
> There is a half baked PR in the works, gh-6269, that tries to unify
> beh
