On Tuesday, December 5, 2017 at 12:40:01 AM UTC+5:30, Jason Maldonis wrote: > I was extending a `list` and am wondering why slicing lists will never > raise an IndexError, even if the `slice.stop` value if greater than the > list length. > > Quick example: > > my_list = [1, 2, 3] > my_list[:100] # does not raise an IndexError, but instead returns the full > list > > Is there any background on why that doesn't raise an IndexError? Knowing > that might help me design my extended list class better. For my specific > use case, it would simplify my code (and prevent `if isinstance(item, > slice)` checks) if the slicing raised an IndexError in the example I gave.
Data Structures have invariants. Some of these are just side-notes… interesting, cute Some are more fundamental, the raison d'être for the data structure Whether the following inv is that fundamental or not I wont offer an opinion It certainly seems important (to me) Python slice inv: (∀ n:ℤ, l:sequence | l[:n] + l[n:] == l) Your preferred inv: (∀ n:ℤ, l:sequence ∧ jason_caveat(n) | l[:n] + l[n:] == l) where def jason_caveat(n,l): return 0 ≤ n ≤ len(l) Do you consider it arguable that your preferred invariant is at least more heavy-weight if not downright clunkier? Note I am not offering a view on this. eg for zip python does this >>> zip([1,2,3], [4,5,6,7,8]) [(1, 4), (2, 5), (3, 6)] I find myself sometimes needing this Sometimes needing it extended to the longer (with what??) Sometimes needing your preferred behavior — an exception On a more fundamental note: def const(x): return 42 has the invariant that const(x) == 42 when x is well-defined This is true for most mainstream languages Lazy functional languages (like Haskell) make a big deal of not having the definedness caveat. People (like me) not quite on the FP bandwagon are conflicted on whether the mathematical elegance is worth the computational mess -- https://mail.python.org/mailman/listinfo/python-list