Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

full_like, ones_like, zeros_like should retain subclasses #2542

Closed
gerritholl opened this issue Nov 5, 2018 · 4 comments
Closed

full_like, ones_like, zeros_like should retain subclasses #2542

gerritholl opened this issue Nov 5, 2018 · 4 comments
Labels
plan to close May be closeable, needs more eyeballs

Comments

@gerritholl
Copy link
Contributor

Code Sample,

# Your code here
import numpy
import xarray

class MyDataArray(xarray.DataArray):
    pass

da = MyDataArray(numpy.arange(5))
da2 = xarray.zeros_like(da)
print(type(da), type(da2))

Problem description

I would expect that type(da2) is type(da), but this is not the case. The type of da is always <class 'xarray.core.dataarray.DataArray'>. Rather, the output of this script is:

<class '__main__.MyDataArray'> <class 'xarray.core.dataarray.DataArray'>

Expected Output

I would hope as an output:

<class '__main__.MyDataArray'> <class '__main__.MyDataArray'>

In principle changing this could break people's code, so if a change is implemented it should probably be through an optional keyword argument to the full_like/ones_like/zeros_like family.

Output of xr.show_versions()

INSTALLED VERSIONS ------------------ commit: None python: 3.7.0.final.0 python-bits: 64 OS: Linux OS-release: 2.6.32-754.el6.x86_64 machine: x86_64 processor: x86_64 byteorder: little LC_ALL: None LANG: en_GB.UTF-8 LOCALE: en_GB.UTF-8

xarray: 0.10.7
pandas: 0.23.2
numpy: 1.15.2
scipy: 1.1.0
netCDF4: 1.4.0
h5netcdf: 0.6.1
h5py: 2.8.0
Nio: None
zarr: None
bottleneck: 1.2.1
cyordereddict: None
dask: 0.18.1
distributed: 1.22.0
matplotlib: 3.0.0
cartopy: 0.16.0
seaborn: 0.9.0
setuptools: 39.2.0
pip: 18.0
conda: None
pytest: 3.2.2
IPython: 6.4.0
sphinx: None

@shoyer
Copy link
Member

shoyer commented Nov 6, 2018

Are there other functions where we don't do this?

I would be happy to accept a fix here. I don't think we need a few keyword argument -- I expect most subclass users would consider this a bug rather than a feature.

We might consider adding an official subclassing APIs like pandas:
https://pandas.pydata.org/pandas-docs/stable/extending.html#extending-subclassing-pandas

gerritholl added a commit to gerritholl/typhon that referenced this issue Nov 13, 2018
Implement a workaround for pydata/xarray#2542
where subclasses are lost by zeros_like.
@stale
Copy link

stale bot commented Oct 12, 2020

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically

@stale stale bot added the stale label Oct 12, 2020
@max-sixty max-sixty removed the stale label Oct 12, 2020
@TomNicholas
Copy link
Member

See #3980 - this issue should be solved as part of #3980, but see that issue for more general discussion of subclassing.

@max-sixty
Copy link
Collaborator

Shall we fold this into #3980? (i.e. I don't think we need an issue for enabling subclassing for each method :) )

@max-sixty max-sixty added the plan to close May be closeable, needs more eyeballs label Oct 25, 2023
@max-sixty max-sixty closed this as not planned Won't fix, can't repro, duplicate, stale Nov 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plan to close May be closeable, needs more eyeballs
Projects
None yet
Development

No branches or pull requests

4 participants