Hacker News new | ask | show | jobs
by macintux 1026 days ago
Then why doesn’t a[1] return None?

I understand the logic behind both decisions, but it’s not surprising that people find it inconsistent and unintuitive.

2 comments

> Then why doesn’t a[1] return None?

Because there would be no way to distinguish between "a[1] contains None" and "a[1]" doesn’t exist.

And with a[1:] returning the empty list there’s no way to distinguish between a is empty and a only has one element.

These are, in the end, relatively arbitrary language design decisions.

When you slice a list, you get a list. When you see there is nothing inside the returning list, you know that means end of list, contains zero element. Slicing and indexing return object at different level.
Slicing a list, when the first index is invalid for that list, could easily throw an exception instead.
This should signal an explicit error, which invalid index is indeed. If user believes for some reason the invalid indexing is ok, then it could be caught and handled. No ambiguity.
I think it is consistent, it works a bit like filtering an element from a mathematical set.

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]

gives `undefined` in JavaScript but it differs from `null` which would be the equivalent to `None` in Python (and I don't think Python has such concept).