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? I’m pretty sure a generic slice-view-wrapper (that just does index arithmetic and delegates) will work correctly on every sequence type. I won’t promise that the one I posted early in this thread does, of course, and obviously we need a bit more proof than “I’m pretty sure…”, but can anyone think of a way a Sequence could legally work that would break this? And I can’t think of any custom features a Sequence might want add to its view slices (or its view-slice-making wrapper). I can definitely see how a custom wrapper for list and tuple could be faster, and imagine how real life code could use it often enough that this matters. But if it’s just list and tuple, CPython’s already full of builtins that fast-path on list and tuple, and there’s no reason this one can’t do the same thing. So, it seems like it only needs a dunder if there are likely to be third-party classes that can do view-slicing significantly faster than a generic view-slicer, and are used in code where it’s likely to matter. Can anyone think of such a case? (At first numpy seems like an obvious answer. Arrays aren’t Sequences, but I think as long as the wrapper doesn’t actually type-check that at __new__ time they’d work anyway. But why would anyone, especially when they care about speed, use a generic viewslice function on a numpy array instead of just using numpy’s own view slicing?) It seems like a dunder is something that could be added as a refinement in the next Python version, if it turns out to be needed. If so, then, unless we have an example in advance to disprove the YAGNI presumption, why not just do it without the dunder? _______________________________________________ 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/G3L6NP4PWPR2O2VSVXGGJNALYECKDG5G/ Code of Conduct: http://python.org/psf/codeofconduct/
