On May 15, 2020, at 18:21, Christopher Barker <pythonchb@gmail.com> wrote:
On May 15, 2020, at 13:03, Christopher Barker <pythonchb@gmail.com> wrote:
>
> Taking all that into account, if we want to add "something" to Sequence behavior (in this case a sequence_view object), then adding a dunder is really the only option -- you'd need a really compelling reason to add a Sequence method, and since there are quite a few folks that think that's the wrong approach anyway, we don't have a compelling reason.
>
> So IF a sequence_view is to be added, then a dunder is really the only option.
Once you go with a separate view-creating function (or type), do we even need the dunder?
Indeed -- maybe not. We'd need a dunder if we wanted to make it an "official" part of the Sequence protocol/ABC, but as you point out there may be no need to do that at all.
That’s actually a what triggered this thought. We need collections.abc.Sequence to support the dunder with a default implementation so code using it as a mixin works. What would that default implementation be? Basically just a class whose __getitem__ constructs the thing I posted earlier and that does nothing else. And why would anyone want to override that default?
Being able to override dunders like __in__ and regular methods like count is useful for multiple reasons: a string-like class needs to extend their behavior for substring searching, a range-like class can implement them without searching at all, etc. But none of those seemed to apply to overriding __viewslice__ (or whatever we’d call it).
Hmm, more thought needed.
Yeah, certainly just because I couldn’t think of a use doesn’t mean there isn’t one.
But if I’m right that the dunder could be retrofitted in later (I want to try building an implementation without the dunder and then retrofitting one in along with a class that overrides it, if I get the time this weekend, to verify that it really isn’t a problem), that seems like a much better case for leaving it out.
Another point: now that we’re thinking generic function (albeit maybe a C builtin with fast-path code for list/tuple), maybe it’s worth putting an implementation on PyPI as soon as possible, so we can get some experience using it and make sure the design doesn’t have any unexpected holes and, if we’re lucky, get some uptake from people outside this thread.