On 2021-09-03 14:01, Kevin Mills wrote:
As I said before, the "1,2,3" in `f(1,2,3)` has a very different
meaning than the "1,2,3" in `d[1,2,3]`. One is a (comma-separated)
list of expressions, and one is a single expression, a tuple.
`*(1,2,3)` does not evaluate to the tuple `(1,2,3)`, so I don't think
expecting it to do so in the context of d[*(1,2,3)] makes sense. And,
I would argue that having it to so would be far more inconsistent -
why does it evaluate to the tuple `(1,2,3)` in the context of
`d[*(1,2,3)]`, but not in the context of `f(*(1,2,3))`?
I agree with others that your proposal would make things confusing.
It's true that `*(1, 2, 3)` doesn't evaluate to the tuple `(1, 2, 3)`,
but nonetheless `*(1, 2, 3)` does expand to something that remains
contained within the argument list where it occurs. Your proposal would
cause the `x` in `[*x]`to "leak" beyond the indexing brackets and (as
you note in another message) would actually create additional indexing
brackets, whereas there's no situation where existing *-expansion
creates additional function calls.
In other words, currently `*` can turn what looks like one function
call with one thing inside it into one function call with several things
inside it. You are proposing to make it so `*` can turn one indexing
operation with one thing inside it into several indexing operations each
with one thing inside it. I think that is quite different.
To my mind, the operation of indexing itself is not sufficiently
parallel to function calls to warrant a crossover of `*` between the
two. A function call can have multiple arguments, but an indexing
operation only ever has one index (albeit that index may be a tuple or
other composite object). So there is no scope for "unpacking" because
there are no extra "slots" (akin to separate arguments) to unpack into.
You're proposing to not just unpack the indexes, but to "unpack" the
entire indexing operation into multiple such operations, which is a
bridge too far for (as it appears to be for others).
Also, from a practical perspective, what would even be the point in
allowing the syntax here if `d[*x]` meant exactly the same thing as
`d[x]` (or `d[tuple(x)]` if it's not already a tuple)?
I agree there would be little point in that. But that doesn't mean
that the `*` is now "free" to be used for some other use in this
context. Rather, because the existing unpacking behavior of `*` doesn't
have much use in an indexing context, that to me means that use of `*`
is "blocked" in this context and we can't use it for anything. It's
better to have it not mean anything at all than have it mean something
different and confusing.
I would support adding some kind of multi-getter function to the
stdlib. I would even support adding multi-get methods to list, dict,
and tuple so that you could call `my_list.multiget(1, 2, 3)` or
`my_dict.multiget(*some_keys)` and have it do a series of nested
indexes. But I don't think we should add syntax for this, or at least I
think we should not use `*`-unpacking-like syntax for it.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/3P5T77YH6VB4OXNQTO5EK4HCCMH3ELYL/
Code of Conduct: http://python.org/psf/codeofconduct/
