why won't slicing lists raise IndexError?

[Jason Maldonis]

I'll try to summarize what I've learned with a few responses in hodge-podge
order and to no one in particular:

>That's a feature dude, not a bug.

Absolutely. I _do not_ think that how slicing works in python should be
changed, but I _do_ want to understand its design decisions because it will
make me a better programmer.

>one thing Python consistently emphasises is making things easy for
>the user, even if that convenience comes at a cost to the implementer.

I completely agree, and I'm always happy to do the work as a developer to
make the user experience better. That's something I really appreciate about
python as well.

>I've got a buffer class with that behaviour which is very useful for
parsing data streams.
[...]
>In summary, I think you should give your LazyList a .extend method to
establish your code's precondition (enough elements) and then you can
proceed with your slicing in surety that it will behave correctly.

Thanks for this detailed response, I'll have to reread it a few times to
understand it but I think I'll understand how I might improve my
implementation from your example. In particular, that last "In summary"
sentence hit on something I'd been thinking about. A `.extend` method might
clean things up nicely.

--
It seems to me that the consensus on the reason for why slices don't throw
IndexErrors is essentially "It's very convenient for them not to" and I'm
just fine with that response (not super thrilled, but happy enough). There
were two comments in particular that sounded pretty good:

>But as a user, I can say that I find the ability to use slices without
checking for
>out of bounds cases or handling exceptions to be really convenient.

That's fair.  The alternative would be something that someone else
mentioned:  `my_string[ : min(n, len(my_string))]` and that's not very
pretty, although I don't think it's absolutely horrible.

And: the use case where you are trying to split a list or string at index
`n` is:  `first_half, second_half = my_string[:n], my_string[n:]`  and if n
> len(my_string) then this use case becomes a bit annoying to write
(although it could use the `min` example above).

So I guess the conclusion (as far as I can tell) is that:  `my_string[:n]`
is more convenient than `my_string[:min(n, len(my_string))]`, and that
sounds okay enough to me.

If I'm being completely honest I kinda like the logical explicitness of the
latter, but it's way less convenient. And I'm 100% sure the people who made
this decision are incredibly smart, and I certainly trust their decision.
Thanks everyone for the responses.


On Mon, Dec 4, 2017 at 6:13 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Tue, Dec 5, 2017 at 10:50 AM, Rick Johnson
> <rantingrickjohnson at gmail.com> wrote:
> > Chris Angelico wrote:
> >> <rantingrickjohnson at gmail.com> wrote:
> >> > Terry Reedy wrote:
> >> >
> >> > [...]
> >> >
> >> >> try:
> >> >>      item = seq[n]
> >> >> except IndexError
> >> >>      do_without_item()
> >> >> else:
> >> >>      process(item)
> >> >>
> >> >> item = seq[n:n+1]
> >> >> if item:
> >> >>      process(item)
> >> >> else:
> >> >>      do_without_item()
> >> >>
> >> >> Many prefer the second.
> >> >
> >> > And they'll prefer it even more when they realize the entire ELSE
> >> > clause of your latter example is superfluous.
> >>
> >> ... how is it superfluous?
> >
> > If the only purpose of an if/else logic structure is to
> > process an arbitrary value _only_ when that value is
> > "truthy", and futhermore, the else clause does nothing of
> > any significance (and in the example provided, appears to
> > be nothing but a placeholder for dead code) then why
> > bother writing the else clause in the first place?
>
> Ahhh, I see how it is. You didn't run the code, ergo you don't
> understand it. Makes perfect sense. :)
>
> Hint: Truthiness is fairly clearly defined here, regardless of the
> value of item.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>