TL;DR: no need to come to consensus about the most "Pythonic" API for a sequence view -- due to potential name clashes, adding a dunder is pretty much the only option.

Details below:

On Fri, May 15, 2020 at 3:50 AM Steven D'Aprano <steve@pearwood.info> wrote:
 I think lst.view[10:20] fits that bill.

Have we forgotten how to look at prior art all of a sudden? Suddenly
been possessed by the spirits of deceased Java and Ruby programmers
intent on changing the look and feel of Python to make it "real object
oriented"? *wink*

I know you winked there, but frankly, there isn't a clear most Pythonic API here. Surely you do'nt think PYhton should have no methods?
 
We have prior art here:
    b'abcd'.memoryview  # No, not this.
    memoryview(b'abcd')  # That's the one.

That's not the ideal example, memoryviews are a real oddball -- they are designed very much to be supported by third party applications. And a memoryview object is a type, unlike, say, len(). Though I guess we'd be talking about a "view" type here as well.

    'abcd'.iter  # No, not that either.
    iter('abcd')  # That's it.

That's closer -- it certainly could have been added to the Iterable ABC.

>  In fairness, I do have to point out that dict views do use a method
interface, but:

1. Dict views came with a lot of backwards-compatibility baggage;

I think this is really the key point here. Not so much the "baggage", but the fact that dicts (and therefor Mappings) have always had .keys, .values, and .items.

so adding the views didn't add or remove any new attributes,

2. There is only a single builtin mapping object, dict, not like
sequences where there are lists, tuples, range objects, strings, byte
strings and bytearrays.

True, but there are multiple Mapping objects in the Standard Library, at it is the intenet that the Mapping ABCs can be used by third party classes -- so I'm not sure that is such a big distinction.

3. Dicts need three kinds of view, keys/items/values, not just one;
adding three new builtin functions just for dicts is perhaps a bit
excessive.

Well, one could have created a MappingView object with three attributes. And maybe a full MApping view would be useful, though I can't think of a use case at the moment.

1. No backwards-compatibility baggage; we can pick the interface which
is the most Pythonic. That's a protocol based on a dunder, not a
method.

I disagree here, but come to the same conclusion: adding an attribute to the Sequence ABC will break backward compatibility -- any Sequence subclass that already has an attribute with that name would break.

We can all argue about what the most Pythonic API is, but the fact is that Python has both "OO" APIs and "function-based" APIs. So either one could be acceptable. But when adding a new name, there is a different impact depending on what namespace it is added to:

A) Adding a reserved word is a Really Big Deal -- only done when absolutely necessary. (and completely off the table for this one)

B) Adding a name to an ABC is a Big Deal -- it could potentially invalidate any subclasses of that ABC -- so suddenly subclasses that worked perfectly fine would be broken. And in the case at hand, numpy arrays do, in fact, already have a .view method that is not the same thing.

C) Adding a builtin name is a Medium Deal, but not too huge -- existing code might overwrite it, but that's only an issue if they want to use the new functionality.

E) Adding a new name to a standard library module is Small Deal -- no third parties should be adding stuff to that namespace anyway (and import * is not recommended) (not that adding new functionality to the stdlib isn't a lift -- but I'm only talking about names now)

F) Adding a new dunder is a Medium Deal -- the dunder names are explicitly documented as being reserved -- so while folks may (and do) use dunder names in third party libraries, it's there problem if something breaks later on. (for instance, numpy used a lot of dunders - though AFAICT, they are all "__array_*", so kinda a numpy namespace.

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.

Then we need to decide on where to put the view-creating-function (and what to call it).

I personally would like to see it as a built in, but I suspect we wont get a lot of support for that on this list.

-CHB


--
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython