On Tue, Jul 21, 2020 at 9:15 AM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Mon, 2020-07-20 at 22:27 -0700, Christopher Barker wrote: > > On Mon, Jul 20, 2020 at 3:17 AM Rhodri James <rho...@kynesim.co.uk> > > wrote: > > > > > Ironically that example pushes me back to -1. It may look a lot > > > like > > > xarray and pandas working, but that just means it should be in > > > xarray > > > and/or pandas. > > > > after following most of this discussion, I'm still not sure what we'd > > get > > with keywords in indexing. > > > > But I do think it would be nice of we could use slice syntax in other > > places. That would allow things like xarray and pandas to use slices > > in > > regular function calls. here's an example from the xarray docs: > > > > da.isel(space=0, time=slice(None, 2)) > > > > wouldn't that be nice as: > > > > da.isel(space=0, time=:2) > > > > or: > > > > da.sel(time=slice("2000-01-01", "2000-01-02")) > > > > could be: > > > > da.sel(time="2000-01-01":"2000-01-02") > > > > As far as I can tell, slicing syntax is currently a syntax error in > > these > > cases, and any others I thought to test. > > > > Is there a reason to not allow syntax for creating a slice object to > > be > > used anywhere (Or more places, anyway)? > > > > By the way, I just noticed this note in the xarray docs: > > > > """Note: We would love to be able to do indexing with labeled > > dimension > > names inside brackets, but unfortunately, Python does yet not support > > indexing with keyword arguments like da[space=0] > > """ > > This would be the thing I would think of first when indexing with > keywords. But, there are a few points about named dimensions: > > First, using it for named dimensions, means you don't actually need to > mix it with normal tuple indexing, mixing both seems rather confusing? > (I cannot think of how to interpret it) > > Second, using keyword arguments for indexing `mode=` or `method=` > switches as Stephan Hoyer mentioned as well seems neat. But I am > worried that the two potential uses clash way too much and my gut > feeling is to prefer the labeled use (which is why I would be extremely > hesitant to add mode-switching things to NumPy or pandas). I might > rather prefer mode switching to be spelled as:: > > temperature.loc(method="nearest")[longitude=longs, latitude=lats] > > even if that has to create an intermediate indexer object (twice, since > `.loc` here is also an index helper object). > (This means axis labels must be strings, that is likely no issue, but > should maybe be mentioned.) > > Thus, for most containers, my knee jerk reaction would be to discourage > the use of keywords in indexing for mode switching. But some of the > use-cases seemed more like class factories, for which there is no clash > of these two concepts/applications. > > That said, labeled dimensions/axis do seem like nice syntax with quite > a bit of potential to me, even with 3 dimensions, remembering whether > your coordinate order was x,y,z or z,x,y or z,y,x can be annoying > (especially if you mix in a 1-D dataset with only a z axis). > For what it's worth, I (as the original author of xarray) totally agree with both Sebastian and Christopher. For indexing labeled arrays, the most compelling use-case is cleaner syntax for creating slice() objects along with keyword arguments for dimension names. I don't particularly care whether that's spelled with [] or (), e.g., da.sel(time="2000-01-01":"2000-01-02") or da.loc[time="2000-01-01":"2000-01-02"] neither of which is currently valid syntax. The further advantages of supporting keyword arguments in __getitem__/__setitem__ would be: 1. We wouldn't need separate methods for positional vs keyword argument indexing. Currently, xarray has both .loc[] and .sel(). 2. We could support matching syntax with keyword arguments in assignment. This is mostly relevant for inexperienced Python users, who will try something like "da.sel(x=0) = value" and encounter a SyntaxError. (This does come up with some regularity, because xarray's target audience includes scientists who often aren't experienced programmers.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P3OYHPIML7EO7JTE4T4MQ6QF36F4VA36/ Code of Conduct: http://python.org/psf/codeofconduct/