On May 15, 2020, at 18:21, Christopher Barker <python...@gmail.com> wrote:
>
>> On Fri, May 15, 2020 at 5:45 PM Andrew Barnert <abarn...@yahoo.com> wrote:
>
>> On May 15, 2020, at 13:03, Christopher Barker <python...@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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VSGQLYF6B25BB6KLZALMYST7IQWMVI3I/
Code of Conduct: http://python.org/psf/codeofconduct/
