.loc should accept out-of-bounds indexers for slices

[shoyer]

pandas 0.14 changed .iloc to accept out-of-bounds indexers for slices. I think we should do the same for .loc, for similar reasons of consistency and efficiency.

Note that this is already currently inconsistent for int and float indexes (not entirely sure why):

>>> pd.Series(range(5), np.arange(5)).loc[-1:]
KeyError
>>> pd.Series(range(5), np.arange(5.0)).loc[-1:]
0    0
1    1
2    2
3    3
4    4
dtype: int64

[jreback]

that last is a big I think

it doesn't make sense to accept out of bounds because by definition labels don't have bounds

maybe show an example

[hayd]

by definition labels don't have bounds

It seems to me by this argument s.loc[a:b] doesn't make sense either (since being orderable implies bounded).

I'm with @shoyer here, behaviour should be consistent with iloc.

[jreback]

no the point is what is out of bounds

I your example say I did
a:20

but 20 is not in the index - what does that mean?

and when would you then raise KeyError
essentially you are saying that you can slice and get back something or an empty list

would be really odd

[jreback]

that said if you have an example eould be best

[hayd]

Sorry I wasn't clear, in the above I meant: doesn't your argument lead to disallowing s.loc[a:b] even with a and b are in the index.

However, I don't see where the ambiguity is regardless of a and b being in the index, in python:

# s.loc[a:b]
[i, val for i, val in s.iteritems() if a <= i <= b]  # or maybe < b

# s.iloc[a:b]
list(s.iteritems())[a:b]

The problem arises if they are not orderable (i.e. but that's independent of whether they're in the index) ?

[jorisvandenbossche]

I think this is a duplicate of #8613 I recently filed.

But I am also in favor allowing out-of-bounds (not included labels) indexers in slices. There could only be some ambiguity with non-orderable values, but I think in most common cases this would be very useful.

[shoyer]

@jorisvandenbossche Oops, I think I even saw that issue a few weeks ago! Let's continue the discussion over there.

I encountered this today as part of my recent indexing deep dive for intervals (#8707).