It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple.
`a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.
I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.
Because there would be no way to distinguish between "a[1] contains None" and "a[1]" doesn’t exist.
These are, in the end, relatively arbitrary language design decisions.
Given a set of sheeps, let x be the five-legged sheep is inconsistent because we know neither the existence or uniqueness of shuch sheep, so it raises an exception.
Given a set of sheeps, let x be the subset of five legged sheeps is the empty set because there is no such sheep.
but this may also just be because I internalised Python's behavior.
Some language have a specific value to denote the first thing, for example:
["a", "b", "c"][4]
This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section.
An empty returned section doesn’t mean the index was out of bounds (`a[0:0]`); if you want to make sure you have to check the length before slicing, like in Go.
When using slice notation, the return value is a sequence, so returning a zero-length sequence is sufficient to communicate you asked for more items than exist.
It may be surprising, but it almost always leads to more ergonomic code.