why won't slicing lists raise IndexError?

[Rick Johnson]

Alexandre Brault wrote:

[...]
    
> process() wasn't defined either, nor were n and seq and yet
> you're not complaining about them.

Why would i? Both are highly relevant to the example of
performing a slice. "Don't throw the baby out with the
bathwater", as they say...

> It seems it was clear to everyone but you that seq was a
> sequence defined elsewhere, n was an index defined
> elsewhere, and both process and do_without_item were
> functions defined elsewhere.

OMG! I never would have guessed that! O_O

And whilst we can see that your cryptology skills are quite
impressive -- and by impressive, i mean, like up there with
some of the best cryptologist in the world, impressive --
your ability to distinguish between the portions of this
teeny tiny example that are _relevant_ to the action of
performing a slice, and the portions that are _irrelevant_
to performing a slice, leads me to the conclusion that your
ability to make simple value judgments is seriously
flawed, or missing altogether.

If we consider the entire working sample that Ned offered
(because Ned is the only person from your side who's
bothered to offer error-free code) and we break this code
down into its relevant parts, starting from the most
relevant part (the actual slice), and extending the scope
outwards from there, each time enveloping only the minimum
structures required to maintain legal code, we will see that
all of the structures *SANS* the else-clause can be
justified. The function can be justified because it wraps
the contents in a self contained reusable code object.
Likewise, the conditional *if-clause* can be justified
because it brings logic into the equation. But the else-
clause is only relevant to the if-clause, and does not offer
_enough_ useful content of its own to validate its own
existence.

> And even if you want to be so incredibly pedantic that
> do_without_item (and only do_without_item, because the rest
> of the code fragment seems to get your seal of approval) is
> not defined, your "functioning equivalent" is still not
> equivalent, because the original code would have raised a
> NameError that yours doesn't.

Oh this is rich. Now i'm wrong because my code executes
_cleanly_? You must be joking!