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 <st...@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
_______________________________________________
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/W767CGGYLIN4HYJL5Y32MCNSPOFEFQCQ/
Code of Conduct: http://python.org/psf/codeofconduct/
