Deprecation cycles to finish for xarray 0.13

[shoyer]

Clean-ups we should definitely do:

• remove deprecated options from xarray.concat (deprecated back in July 2015!):

  xarray/xarray/core/concat.py

  Lines 114 to 144 in 79dc7dc

  	if dim is None:
  	warnings.warn(
  	"the `dim` argument to `concat` will be required "
  	"in a future version of xarray; for now, setting it to "
  	"the old default of 'concat_dim'",
  	FutureWarning,
  	stacklevel=2,
  	)
  	dim = "concat_dims"
  	if indexers is not None: # pragma: no cover
  	warnings.warn(
  	"indexers has been renamed to positions; the alias "
  	"will be removed in a future version of xarray",
  	FutureWarning,
  	stacklevel=2,
  	)
  	positions = indexers
  	if mode is not None:
  	raise ValueError(
  	"`mode` is no longer a valid argument to "
  	"xarray.concat; it has been split into the "
  	"`data_vars` and `coords` arguments"
  	)
  	if concat_over is not None:
  	raise ValueError(
  	"`concat_over` is no longer a valid argument to "
  	"xarray.concat; it has been split into the "
  	"`data_vars` and `coords` arguments"
  	)

  (edit by @max-sixty )
• argument order in DataArray.to_dataset (also from July 2015)

  xarray/xarray/core/dataarray.py

  Line 491 in 41fecd8

  if dim is not None and dim not in self.dims:

  (edit by @max-sixty )
• remove the warning back reindex with variables with different dimensions (from 2017). This could either be replaced by replacing dimensions like sel or by simply raising an error for now and leaving replacing dimensions for later: indexing with broadcasting #1639):

  xarray/xarray/core/alignment.py

  Lines 389 to 398 in 79dc7dc

  	if isinstance(indexer, DataArray) and indexer.dims != (dim,):
  	warnings.warn(
  	"Indexer has dimensions {:s} that are different "
  	"from that to be indexed along {:s}. "
  	"This will behave differently in the future.".format(
  	str(indexer.dims), dim
  	),
  	FutureWarning,
  	stacklevel=3,
  	)

  (edit by @max-sixty )
• remove xarray.broadcast_array, deprecated back in 2016 in 52ee95f (edit by @max-sixty )
• remove Variable.expand_dims (deprecated back in August 2017), whose implementation actually looks like it's already broken:

  xarray/xarray/core/variable.py

  Lines 1232 to 1237 in 41fecd8

  	warnings.warn(
  	"Variable.expand_dims is deprecated: use " "Variable.set_dims instead",
  	DeprecationWarning,
  	stacklevel=2,
  	)
  	return self.expand_dims(*args)

  (edit by @max-sixty )
• stop supporting a list of colors in the cmap argument (dating back to at least v0.7.0):

  xarray/xarray/plot/utils.py

  Lines 737 to 745 in d089df3

  	# we should not be getting a list of colors in cmap anymore
  	# is there a better way to do this test?
  	if isinstance(cmap, (list, tuple)):
  	warnings.warn(
  	"Specifying a list of colors in cmap is deprecated. "
  	"Use colors keyword instead.",
  	DeprecationWarning,
  	stacklevel=3,
  	)

  (edit by @max-sixty )
• push the removal of the compat and encoding arguments from Dataset/DataArray back to 0.14. These were only deprecated 7 months ago in deprecate compat & encoding #2703. (edit by @max-sixty )

Clean-ups to consider:

• switch the default reduction dimension of groupby and resample? (Future warning for default reduction dimension of groupby #2366) This has been giving a FutureWarning since v0.11.0, released back in November 2018. We could also potentially push this back to 0.14, but these warnings are a little annoying...
• deprecate auto_combine (API for N-dimensional combine #2616) only since 29 June 2019, so that should be pushed.

[mathause]

stop supporting a list of colors in the cmap argument

I am a bit worried about the 3rd last item on your list. I currently still rely on this behavior because the alternative does not work for me, see #3284.

[shoyer]

stop supporting a list of colors in the cmap argument

I am a bit worried about the 3rd last item on your list. I currently still rely on this behavior because the alternative does not work for me, see #3284.

OK, we should put this off until the alternative works! But I do think we want to stop overloading cmap in an incompatible way.

[max-sixty]

@shoyer I edited your comment to check-off the ones in #3292, hope that's OK. (would be good to have a system from GH that didn't involve free editing of others' comments!)

[max-sixty]

I think all the 'must-dos' are done

[dcherian]

stop supporting a list of colors in the cmap argument

I am a bit worried about the 3rd last item on your list. I currently still rely on this behavior because the alternative does not work for me, see #3284.

@mathause Does your PR mean that we can go forward with the deprecation then?

[mathause]

Yes, fine for me.

[dcherian]

We were also planing to deprecate auto_combine for 0.13 but we've been warning about that only since 29 June, 2019 so that should be pushed to 0.14. I've added this to the list.

[shoyer]

Yeah, there's also some question about if combine_nested() and combine_by_coords() really solve all the use-cases of auto_combine(). For example, a bunch of files that don't contain the concatenated dimension and have different variables can be combined automatically by auto_combine() but not combine_by_coord().

…

On Fri, Sep 13, 2019 at 9:03 AM Deepak Cherian ***@***.***> wrote: We were also planing to deprecate auto_combine for 0.13 but we've been warning about that only since 29 June, 2019 so that should be pushed to 0.14. I've added this to the list. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3280?email_source=notifications&email_token=AAJJFVQWOC4UEA6LGUYMJALQJO2UNA5CNFSM4ITUC3R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6VO4YI#issuecomment-531295841>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJJFVQBN7OLZHD3VOKKBATQJO2UNANCNFSM4ITUC3RQ> .

[dcherian]

#3313 and #3314 should be looked over by someone who knows the auto_combine and groupby code.