On Sun, Aug 23, 2020 at 10:48 AM Stefano Borini <stefano.bor...@gmail.com>
wrote:
> When you have a getitem operation, you are acting on a set of axes.
> e.g. a[4,5,6] acts on three axes. The first axis index is 4, the
> second is 5 and the third is 6.
> These axes currently are anonymous, but the whole idea is that a name
> could be assigned to them.
>
> Which is kind of asymmetric with the whole args/kwargs structure of a
> function. In a function, your "axes" (which are your arguments)
> _always_ have a name. Not so in getitem operations:
> naming axes is optional. There's no such thing as optionally named
> function arguments.
>
> 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")
>
> Now, I personally don't like this solution, especially because now
> passing names depend if it was declared in the signature to begin
> with, but I am just throwing also this idea in the mix. Apologies if
> it was already passed by someone else.
>
> My point is that the core of the issue is to name axes (with loose
> definition of what axes are. In the case of generic types, they are
> the degrees of freedom of the type).
> How these names are then handled (and recognised) _could_ be put in
> the hands of the user (in other words, python will say "here are the
> names, I have no idea if they mean something or not. it's your duty to
> find out, if you care about it")
>
It's a way of handling it I for one haven't seen suggested yet. I don't
think I like it either.
I suppose a trouble with the basis of this is the assumption that most
users will be using what's inside a [ ] to define axes. Maybe this is
correct. But it could easily be that the most popular usage of providing
these named indices will be more akin to named arguments.
Indeed, nearly all of the discussion (that I've seen at least) has seemed
to presuppose that adding the ability to provide these named indices is
really going to be more akin to a function call.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
_______________________________________________
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/WUIMDQPLUHAF3XPJWSSVB5VBHHJQQNHT/
Code of Conduct: http://python.org/psf/codeofconduct/
