On Sun, Aug 23, 2020 at 03:47:59PM +0100, Stefano Borini wrote:
> I am currently in the process of scouting the whole set of threads and
> rewrite PEP-472, somehow.
> but just as a 2 cents to the discussion, the initial idea was focused
> on one thing only: give names to axes.
That is one of the motivating use-cases, but "axis name" is not the only
use-case for this. Right now I would give my left arm for the ability to
write `matrix[row, column, base=1]` to support standard mathematical
notation which starts indexes at 1 rather than 0.
> Given the asymmetry, and the need for backward compat, would it make a
> possible solution to have __getitem__() accept one additional argument
> "names" containing a tuple with the names?
>
> e.g. if you call a[1,2] __getitem__(index, names) will receive
> index=(1,2), names=(None, None)
> if you call a[foo=1, bar=2] __getitem__ will receive index=(1,2),
> names=("foo", "bar")
> if you call a[1, bar=2] __getitem__ will receive index=(1,2),
> names=(None, "bar")
Advantages over the other suggestions already made: none.
Disadvantages: everything.
(1) Fragile. You mentioned backwards compatibility, so presumably a
single, non-comma separated argument won't receive a name argument at
all:
a[index]
=> a.__getitem__(index)
rather than receiving a "names=None" or "names=()" argument.
That will at least allow code that never uses a comma in the subscript
to work unchanged, but it will break as soon as somebody includes a
comma without a protective set of parentheses:
a[(2,3,4)]
=> a.__getitem__((2, 3, 4))
a[2,3,4]
=> a.__getitem__((2, 3, 4), names=(None, None, None)
So the first version is backwards compatible but the semantically
identical second version breaks.
(2) Not actually backwards compatible. Every `__getitem__` will need to
have a new "names" parameter added or it will break even if no keywords
are used. (See point 1 above.)
(3) We already have two models for matching up arguments to formal
parameters: there is the standard model that uses named parameters and
matches arguments to the named parameter, used everywhere in functions
and methods; and there is the slightly odd, but long established,
convention for subscripts that collects comma-separated positional
arguments into a tuple before matching them to a single named parameter.
This proposal adds a third way to do it: split the parameter names into
a separate positional argument.
(4) This will require the method to do the work of matching up names
with values:
- eliminate values which are paired up with None (positional only);
- match up remaining values with the provided names;
- deal with duplicate names (raise a TypeError);
- deal with missing names (raise a TypeError or provide a default);
- deal with unexpected names (raise a TypeError).
We get this for free with normal parameter passing, the interpreter
handles it all for us. This proposal will require everyone to do it for
themselves.
I once had to emulate keyword-only arguments in Python 2, for a project
that required identical signatures in both 2 and 3. So I wrote the
methods to accept `**kwargs` and parsed it by hand. It really made me
appreciate how much work the interpreter does for us, and how easy it
makes argument passing.
If I had to do this by hand every single time I wanted to support
keyword arguments, I wouldn't support keyword arguments :-)
(5) Being able to see the parameters in the method signature line is
important. It is (partially) self-documenting, it shows default values,
and allows type-hints. There are lots of introspection tools that
operate on the signatures of functions and methods. We lose all of that
with this.
> Now, I personally don't like this solution
Then why suggest it?
Can we just eliminate this from contention right now, without a six week
debate about ways to tweak it so that it's ever so marginally less
awful? You're the PEP author, you don't have to propose this as part of
your PEP if you don't like it. Anyone who thinks they want this can
write a competing PEP :-)
[...]
> But I would like to raise another question. Is there another language
> out there that provides the same feature? I am not aware of any.
It quite astonishes me that the majority of programming languages don't
even supported named keyword arguments in function calls, so I would not
be surprised if there are none that support named arguments to
subscripting.
--
Steven
_______________________________________________
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/CKWE3U3PS2DZSHSPZ5XBOBGL3K2YMV3D/
Code of Conduct: http://python.org/psf/codeofconduct/
