thanks @dcherian & @phausamann !

Sounds good. Just to mention that it might be easy to implement by stacking the arrays using .to_array and then just using DataArray.plot.line.

calling @dcherian for the rescue!

@crusaderky @corora Thanks for your comments, glad to see that there's a more efficient way to do it. The question is do you think it's useful enough to justify adding it as a built in function. I end up using my solution quite often

Thanks @dcherian ! Glad to see this finally merged

Thanks for this

On Mon, Aug 5, 2019 at 12:04 PM Deepak Cherian notifications@github.com wrote:

Yay, tests pass. I'll merge in a few days (cc @pydata/xarray https://github.com/orgs/pydata/teams/xarray, @yohai https://github.com/yohai )

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/2277?email_source=notifications&email_token=ABPA5PNDIYQDJME4CUJREDDQDBFQNA5CNFSM4FJJSKRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3SJCVA#issuecomment-518295892, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPA5PMUANDUGDQKZHTIPYDQDBFQNANCNFSM4FJJSKRA .

-- Yohai Bar Sinai Post Doctoral Fellow John A. Paulson School of Engineering and Applied Sciences Harvard University

@dcherian @shoyer I think it's ready to merge

turns out it was an easy fix. But now I wonder if we somehow screwed up other plotting functionalities without noticing (I checked a few but found nothing)

Hold the press! we can't merge. It seems like the new functionality messes up the faceted lineplots. If we define ds=xr.tutorial.scatter_example_dataset() then current behavior is :

ds.A.plot(col='x', row='w', hue='z'):

but with the pull request we screw up the legend

I need to look at this.

Also - kinda unsettling that this was not picked up by any unit test.

@dcherian @shoyer I can't seem to build the docs on my machine because of cartopy or something. Is there a way to access a built version from travis or something like that?

I'll try to have a look tonight

On Thu, Jun 20, 2019, 11:30 Stephan Hoyer notifications@github.com wrote:

Tests seem to be failing due to lint errors, see #2277 (comment) https://github.com/pydata/xarray/pull/2277#issuecomment-447607250

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/2277?email_source=notifications&email_token=ABPA5POP2JLG6ETE45NGEWDP3OPDBA5CNFSM4FJJSKRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFYT2Y#issuecomment-504072683, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPA5PN4I5RBWUDFYBCAZU3P3OPDBANCNFSM4FJJSKRA .

Anything I can do?

To make things concrete, the solution that I have in mind is as simple as adding this function to DataArray:

python def __format__(self, format_spec): return self.values.__format__(format_spec)

Here's one use case I have encountered: python ds=xr.Dataset({'A':(['x','y','z'], np.random.rand(40,40,3)), 'B':(['z'], np.random.randn(3))}, coords={'z':[31,42,45]}) fg=ds.A.plot(col='z') for ax, d in zip(fg.axes.flat, fg.name_dicts.flat): t=ax.get_title() ax.set_title('{} and B(z)={:1.2}'.format(t, ds.sel(**d).B))

This way, if you want to vectorize a __format__ on an array can you not simply do ```python ar = xr.DataArray([39, 103, id(xr)]) print('{:3.3f} {:3.3e} {:x}'.format(*ar))

prints 39.000 1.030e+02 10e5bb548

```

I tend towards the former, to coerce singleton arrays to behave as scalars of their dytpe. I think it makes more sense in terms of use cases (at least everything that I needed). I don't mind implementing it if there is agreement as to which of the two to do.

These behaviors would definitely conflict for scalar objects -- in the second case, we would still want to include some indication that it's an xarray.DataArray. NumPy doesn't have a conflict because indexing an array results in a NumPy scalars, which prints like Python builtin scalars.

@shoyer I don't see why would that be the case. If I format something as '{:04d} {:3.5e} {:2.3E}'.format(dataarray) or whatnot, I would expect that the average user would expect to get '0043 4.35000e+02 2.450E+02' in return, without any indication that these are data arrays.

Could we call this mark_size instead of scatter_size? The later sounds a little awkward to me.

I think matplotlib uses markersize

On the one hand I agree, but note that the same behavior works for numpy arrays

```python import numpy as np a=np.array([1,2,3,4]) ' '.join('{:d}'.format(v) for v in a)

prints '1 2 3 4'

```

@shoyer your fix works. I think it's ready to merge.

My feeling is that "legend" applies to both a color bar and a discrete legend (or other more complicated stuff too) but I am not a native English speaker. I'm fine with whichever decision.

I agree that my solution is a bit hacky, but from a computational cost viewpoint they are identical (or almost. I don't think there's a way to avoid one if statement per call of where). I thought my solution is good because catching this at a high level captures all possible edge cases that we might miss at lower ones. But I can try to do what you suggested to.

@dcherian here: #2749. I think it's very simple, but I might be missing something

OK. So no point in fixing this. Thanks.

OK I think I know what's going on. On a fresh environment it works, but then I installed ipykernel so that I could fiddle around on Jupyter and after that it doesn't work anymore. I don't know if it's of interest to try to fix this or not, I'll let you decide.

Here are the package changes when installing ipykernel

```bash (test_env)$ conda install ipykernel Collecting package metadata: done Solving environment: done

Package Plan

environment location: /Users/yohai/miniconda3/envs/test_env

added / updated specs: - ipykernel

The following NEW packages will be INSTALLED:

ipykernel conda-forge/osx-64::ipykernel-5.1.0-py37h24bf2e0_1002 jupyter_client conda-forge/noarch::jupyter_client-5.2.4-py_1 jupyter_core conda-forge/noarch::jupyter_core-4.4.0-py_0 libsodium conda-forge/osx-64::libsodium-1.0.16-h1de35cc_1001 pyzmq conda-forge/osx-64::pyzmq-17.1.2-py37h111632d_1001 zeromq conda-forge/osx-64::zeromq-4.2.5-h0a44026_1006

The following packages will be UPDATED:

expat conda-forge::expat-2.2.5-h0a44026_1002 --> pkgs/main::expat-2.2.6-h0a44026_0 libpq conda-forge::libpq-10.6-hbe1e24e_1000 --> pkgs/main::libpq-11.1-h051b688_0 openssl 1.0.2p-h1de35cc_1002 --> 1.1.1a-h1de35cc_1000 pcre conda-forge::pcre-8.41-h0a44026_1003 --> pkgs/main::pcre-8.42-h378b8a2_0 postgresql conda-forge::postgresql-10.6-ha1bbaa7~ --> pkgs/main::postgresql-11.1-h051b688_0 python conda-forge::python-3.7.1-h145921a_10~ --> pkgs/main::python-3.7.2-haf84260_0

The following packages will be SUPERSEDED by a higher-priority channel:

cryptography conda-forge::cryptography-2.5-py37hdb~ --> pkgs/main::cryptography-2.4.2-py37ha12b0ac_0 curl conda-forge::curl-7.63.0-heae2a1f_1000 --> pkgs/main::curl-7.63.0-ha441bb4_1000 krb5 conda-forge::krb5-1.16.3-h24a3359_1000 --> pkgs/main::krb5-1.16.1-hddcf347_7 libcurl conda-forge::libcurl-7.63.0-h76de61e_~ --> pkgs/main::libcurl-7.63.0-h051b688_1000 libgdal conda-forge::libgdal-2.4.0-h89caebc_1~ --> pkgs/main::libgdal-2.3.3-h0950a36_0

The following packages will be DOWNGRADED:

libssh2 1.8.0-hf30b1f0_1003 --> 1.8.0-1 rasterio 1.0.13-py37h3683dd5_1 --> 1.0.13-py37h54a03ab_0 ```

Works fine. Thanks. It does suggest there's a problem though, no? Why are there two separate environment specs?

This looks great! Thanks @dcherian!

The only comment I have is with respect to the part of the API that specifies whether a legend should be drawn or not. For non-numerical hues (or when hue_style='discrete') the legend is turned off by add_legend=False but for numerical ones by add_colorbar=False, which might be not intuitive and might require manual editing in various places if you change your mind between a discrete and continuous legend. I would suggest to either unify both options to one, or make them interchangeable (if not contradicting).

something like:

python if xor(add_legend, add_colorbar): #decide according to plot type: if it's non-numeric or `hue_style='discrete'` # then use value of add_legend, else use value of add_colorbar elif add_legend or add_colorbar: #plot legend according to current logic

but really there should only be one allowable keyword here I think

@dcherian thanks for nudging. Actually I'm in a pretty stressed time now. I will be able to pick this up in a few months, but I wouldn't mind if someone else does it in the meantime (I don't think there's a lot of work there)

thanks @dcherian for the review. I'll fix the code when I get to it later this week,

Regarding the size and marker style - I'm not sure it makes sense to duplicate this functionality. Is it not easier to stack the two data arrays into one, use to_pandas and then just use seaborn directly? The reason I started this PR in the first place is that I happened to do relatively simple scatter plots quite often, so I thought it'd be handy. but for more elaborate ones I would use a dedicated tool like seaborn.

I don't have an opinion about naming variables and would be happy with whatever decision y'all make.

For the code -- I added tests and changed the logic a bit. Following @dcherian's suggestion, now the default behavior is no longer coloring hues with discrete values (legend) but rather with a continuous scale (colorbar). It does make actually more sense and I think it should also be the default behavior for regular line plots. This is the API now:

python A = xr.DataArray(np.zeros([3, 20, 4, 4]), dims=[ 'x', 'y', 'z', 'w'], coords=[np.sort(np.random.randn(k)) for k in [3,20,4,4]]) ds=xr.Dataset({'A': A.x+A.y+A.z+A.w, 'B': -0.2/A.x-2.3*A.y-np.abs(A.z)**0.123+A.w**2}) ds.A.attrs['units'] = 'Aunits' ds.B.attrs['units'] = 'Bunits' ds.z.attrs['units'] = 'Zunits' ds.plot.scatter(x='A', y='B')

Specifying hue creates a colorbar: python ds.plot.scatter(x='A',y='B', hue='z') If, however, the hue dimension is not numeric, then a legend is created: python ds['z']= ['who', 'let','dog','out'] ds.plot.scatter(x='A',y='B', hue='z')

If you want a discrete legend even for numeric hues, you can specify it explicitly: python ds.plot.scatter(x='A',y='B', hue='w', discrete_legend=True)

I am a bit bothered by the fact that this is not only a different coloring method, it's a very different style altogether (under the hood using plot instead of scatter). I don't know if it's a good thing or a bad thing that the same function can produce very different looking figures. Input will be welcome about that.

Of course, faceting works as you think it should: python ds.plot.scatter(x='A',y='B', hue='z',col='x') ds.plot.scatter(x='A',y='B', hue='w',col='x', col_wrap=2)

Sorry, I messed this up. Opening a new fresh pull request

@fujiisoup Great feature! thanks. There's a typo ('rondomloy') in the documentation: https://github.com/pydata/xarray/blame/master/doc/interpolation.rst#L192

OK, somehow the rebasing thing broke everything and I am at a loss. @shoyer, @dcherian please guide me on how to proceed. Sorry.

Thanks @shoyer. I fixed everything except for the coverall part, which is weird. The lines it marks as untested are the function _line_facetgrid, which the main function that performs all of the testing. I suspect that it simply doesn't run my new tests for some reason. When I run pytest locally these lines do get tested (I verified by adding print commands there). Should I add decorators like pytest.mark.somethingfor coverall to notice these tests?

I wrote some tests and also followed @shoyer's suggestion to make the plots look more like seaborn. Here's what it looks like now:

I also had to refactor the code adding legend to a line plot to avoid duplicities.

@jhamman @shoyer Sorry for being a noob, but what exactly do you mean by "add some basic unit tests"? you mean writing new functions that will verify that stuff works as it should, or that the new addition does not mess up previous plotting behavior?

was simpler than I thought. @shoyer I added the plots.

Example code to demonstrate functionality:

```python import xarray as xr import numpy as np import pandas as pd

np.random.seed(0) tm = pd.date_range('2000-01-01', end='2000-01-02', freq='H') d4 = xr.DataArray(np.random.randn(len(tm), 6, 3, 3), dims=['time', 'x', 'text_dim', 'z'], coords=[tm, range(6), ['foo', 'bar', 'foobar'], [3.5, 4.9, 6.7]], name='arr_name') d3 = d4[..., 0].drop('z') d2 = d3[..., 0].drop('text_dim')

generate a faceted 4-dimensional plot:

d4.plot(hue='text_dim', col='x', row='z')

or equivalently:

d4.plot.line(x='time', col='x', row='z')

````

python d3.plot(col='x', row='text_dim')

python d2.plot(hue='x')

python d3.plot.line(col='x', col_wrap=3, hue='text_dim')

I found some bugs. I'll reopen when I fix them.

Created a pull request: https://github.com/pydata/xarray/pull/2107 This is my first time contributing to an open-source project so be gentle. Any feedback will be appreciated.

@shoyer I can try to work on it and already tried to dig through the code to see how it can be done. If I commit to doing that then (a) it'll take time and (b) I'll probably bug you to help me...