where ignores incorrectly typed arguments

[max-sixty]

MCVE Code Sample

I optimistically tried passing a lambda to where* to avoid another .pipe. To my surprise it ran! But unfortunately it just ignored the lambda, as though all values were True.

In [1]: import xarray as xr                                                                                                                                         

In [2]: import numpy as np                                                                                                                                          

In [3]: da = xr.DataArray(np.random.rand(2,3))                                                                                                                      

In [4]: da.where(da > 0.5)                                                                                                                                          
Out[4]: 
<xarray.DataArray (dim_0: 2, dim_1: 3)>
array([[       nan, 0.71442406,        nan],
       [0.55748705,        nan,        nan]])
Dimensions without coordinates: dim_0, dim_1

# this should fail!

In [5]: da.where(lambda x: x > 0.5)                                                                                                                                 
Out[5]: 
<xarray.DataArray (dim_0: 2, dim_1: 3)>
array([[0.26085668, 0.71442406, 0.05816167],
       [0.55748705, 0.15293073, 0.12766453]])
Dimensions without coordinates: dim_0, dim_1

Expected Output

Raise a TypeError when passed the lambda

* (maybe that could work, but separate discussion)

Output of xr.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 3.6.8 (default, Aug 7 2019, 17:28:10) [...] python-bits: 64 OS: Linux OS-release: [...] machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_US.utf8 LOCALE: en_US.UTF-8 libhdf5: 1.10.4 libnetcdf: None

xarray: 0.14.1
pandas: 0.25.3
numpy: 1.18.1
scipy: 1.4.1
netCDF4: None
pydap: None
h5netcdf: None
h5py: 2.10.0
Nio: None
zarr: None
cftime: None
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: None
distributed: None
matplotlib: 3.1.2
cartopy: None
seaborn: 0.10.0
numbagg: None
setuptools: 45.0.0
pip: 20.0.2
conda: None
pytest: 5.3.2
IPython: 7.11.1
sphinx: 2.3.1

[max-sixty]

Would we want callables to be acceptable arguments to functions like where, assign, loc?

[shoyer]

This is a NumPy thing, too:

In [6]: np.where(lambda: None, 1, 2)
Out[6]: array(1)

I think the problem is that functions cast to True with bool.

(I don't really understand why that is the case, but it does seem to be well-established behavior in Python)

[max-sixty]

👍

a) should we type check before we pass to numpy?
b) should we support single-argument callables?

[keewis]

The docs state that the builtin bool returns True for all objects unless __bool__ is defined or __len__ returns 0 (function objects don't define either so they use the fallback). I'm not sure why, but I suspect it is the way it is to make

if obj:
    ...

equivalent to

if obj is not None:
    ...

That said I really like the callable support of pandas (e.g. Series.where), so maybe we should add that too?

[shoyer]

I'd be OK with callable support in where() and other methods, as long as we have a clear policy about what methods should/will support it.

…

On Mon, Feb 17, 2020 at 11:29 AM keewis ***@***.***> wrote: The docs <https://docs.python.org/3/library/stdtypes.html#truth-value-testing> state that the builtin bool returns True for all objects unless __bool__ is defined or __len__ returns 0 (function objects don't define either so they use the fallback). I'm not sure why, but I suspect it is the way it is to make if obj: ... equivalent to if obj is not None: ... That said I really like the callable support of pandas (e.g. Series.where), so maybe we should add that too? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3770?email_source=notifications&email_token=AAJJFVRYEDNJXFBFUBOKMI3RDLQRPA5CNFSM4KVTARTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL7OM5Y#issuecomment-587130487>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJJFVQWSRLFT7AXVGGWWULRDLQRPANCNFSM4KVTARTA> .