On Sun, May 10, 2020 at 9:36 PM Andrew Barnert firstname.lastname@example.org wrote:
<lots of stuff I agree with, and don't really have any more to say about >
Here is where I think you (Andrew) and I (Chris B.) differ in our goals. My
goal here is to have an easily accessible way to use the slice syntax to get an iterable that does not make a copy.
It’s just a small difference in emphasis. I want a way to get a non-copying slice, and I’d really like it to be easily accessible—I‘d grumble if you didn’t make it a member, but I’d still use it.
Hmm -- I wasn't sure how key the "slice" part was -- there are, of course, other uses for views. But we're on the same page as to preferences.
However, there is one potential problem with the property I hadn’t thought of until just now: I think people will understand that mylist.view[2:] is not mutable, but will they understand that mystr.view[2:] is not a string? I’m pretty sure that isn’t a problem for seqview(mystr)[2:], but I’m not sure about mystr.view[2:].
One more issue around the whole "a string is sequence of strings" thing :-) Of course, it *could* be a string -- not much difference with immutables. Though I suppose if you took a large slice of a large string, you probably don't want the copy. But what *would* you want to do with it.
but if you had a view of a slice, and it was a proper view, it might be pretty poky for many string operations, so probably just as well not to have them.
But notice that if you use the Mapping mixin to define the methods for you,
it does make sure you get the right views. Maybe that’s sort of a precedent for what you’re looking to do?
yup -- that does sound like a similar idea.