Slicing selection not aligned on "Python standards"

[OBeaude]

Starting recently with Linopy, I discovered that, applying a slicing operation on a variable (with .loc[idx_start: idx_end] method), does select the last index idx_end, which seems non-aligned on some standards of key Python packages (e.g., numpy, pandas).

Is it directly related to xarray basis of Linopy - and in turn, not easy to be corrected, or could it evolve in a future version of Linopy?

Thank you

[FabianHofmann]

thank you for raising the issue, this is indeed something unexpected. this will be something for a breaking change in version 1.0

[aurelije]

@FabianHofmann milestone should be v1.0

[FabianHofmann]

thanks :), fixed it

[FBumann]

@FabianHofmann Im currently looking into all the arithmetics and predictable behaviour stuff.
I would argue that the behavior flagged here is actually desired.

linopy follows the pandas/xarray indexing conventions, which split label and positional
indexing across separate accessors:

• .loc / .sel — label-based. [a:b] selects the closed interval [a, b], so the
  endpoint is included. Same as pandas.Series.loc[a:b] and xarray.DataArray.loc[a:b].
• .isel / [...] — positional. [a:b] is standard Python/numpy, endpoint excluded.

m = linopy.Model()
x = m.add_variables(coords=[pd.RangeIndex(10)], name="x")

x.loc[2:5] # [2, 3, 4, 5] label, inclusive
x.isel(dim_0=slice(2, 5)) # [2, 3, 4] positional, exclusive
x[2:5] # [2, 3, 4] positional, exclusive

So the inclusive .loc is working as intended.
The exclusive-end behavior expected here is the positional convention, which is already available via .isel or plain [...].

I would suggest closing this as working-as-intended, or turning it into a short docs task
to spell out the label-vs-positional split in the indexing docs.

[FabianHofmann]

@FabianHofmann Im currently looking into all the arithmetics and predictable behaviour stuff. I would argue that the behavior flagged here is actually desired.

linopy follows the pandas/xarray indexing conventions, which split label and positional indexing across separate accessors:

• .loc / .sel — label-based. [a:b] selects the closed interval [a, b], so the
  endpoint is included. Same as pandas.Series.loc[a:b] and xarray.DataArray.loc[a:b].
• .isel / [...] — positional. [a:b] is standard Python/numpy, endpoint excluded.

m = linopy.Model()
x = m.add_variables(coords=[pd.RangeIndex(10)], name="x")

x.loc[2:5] # [2, 3, 4, 5] label, inclusive
x.isel(dim_0=slice(2, 5)) # [2, 3, 4] positional, exclusive
x[2:5] # [2, 3, 4] positional, exclusive
So the inclusive .loc is working as intended. The exclusive-end behavior expected here is the positional convention, which is already available via .isel or plain [...].

I would suggest closing this as working-as-intended, or turning it into a short docs task to spell out the label-vs-positional split in the indexing docs.

confirmed, it is simply different conventsions on labels and integer slices