`{full,zeros,ones}_like` should return objects with the same type as the input object

[malmans2]

What happened?

I'm getting issues using mypy with the changes to the typing of {full,zeros,ones}_like introduced in #6611.

cc: @headtr1ck

What did you expect to happen?

I think the object returned should be of the same type as the input object rather than Union[Dataset, DataArray]. For example, I don't think running mypy on the code below should return an error.

Minimal Complete Verifiable Example

import xarray as xr

def test_zeros_like(da: xr.DataArray) -> xr.DataArray:
    return xr.zeros_like(da)

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

test.py:4: error: Incompatible return value type (got "Union[Dataset, DataArray]", expected "DataArray")
Found 1 error in 1 file (checked 1 source file

Anything else we need to know?

mypy                      0.950           py310h6c45266_0    conda-forge
mypy_extensions           0.4.3           py310h2ec42d9_5    conda-forge

Environment

INSTALLED VERSIONS

commit: None
python: 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:43:32) [Clang 12.0.1 ]
python-bits: 64
OS: Darwin
OS-release: 21.5.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: None
LOCALE: (None, 'UTF-8')
libhdf5: None
libnetcdf: None

xarray: 2022.3.1.dev111+g4da7fdbd
pandas: 1.4.2
numpy: 1.22.3
scipy: 1.8.1
netCDF4: None
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: 2.11.3
cftime: None
nc_time_axis: None
PseudoNetCDF: None
rasterio: 1.2.10
cfgrib: None
iris: None
bottleneck: None
dask: 2022.05.0
distributed: 2022.5.0
matplotlib: None
cartopy: None
seaborn: None
numbagg: None
fsspec: 2022.5.0
cupy: None
pint: None
sparse: None
flox: None
numpy_groupies: None
setuptools: 62.3.2
pip: 22.1.1
conda: None
pytest: 7.1.2
IPython: None
sphinx: None

[headtr1ck]

Nice find.
Was a bug in the overloads, the PR should fix it.

If the bound TypeVar support of mypy would not be so buggy we could move to a simpler solution that is less error prone...