On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine firstname.lastname@example.org wrote:
It has the same capabilities, the question is whether it has any
additional abilities that would justify the added complexity.
The most obvious additional ability is that always >>> d[SOME_EXPRESSION] is equivalent to >>> d[key] for a suitable key.
This is a capability that we already have, which would sometimes be lost under the scheme you support. Also lost would be the equivalence between
val = d[key] getter = operator.itemgetter(key) val = getter(d)
More exactly, sometimes it wouldn't be possible to find and use a key. Docs would have to be changed. See: https://docs.python.org/3/library/operator.html#operator.itemgetter
As I understand it, xarray uses dimension names to slice data. Here's an example from
http://xarray.pydata.org/en/stable/indexing.html#indexing-with-dimension-nam... >>> da[dict(space=0, time=slice(None, 2))]
Presumably, this would be replaced by something like >>> da[space=0, time=:2]
Was the slicing notation already explicitly proposed for kwargs? I find it too similar to the walrus operator when the first argument is missing.
I could only find an example in this section https://www.python.org/dev/peps/pep-0472/#use-cases, but the first argument is defined.
Now, the commands
da[space=0, time=:2] da[space=0, time=:2] = True del da[space=0, time=:2]
would at the begging of the call, presumably, do the same processing on the keyword arguments. (Let this stand for a wide range of examples.)
It is arguable that making it easier for the implementer of type(da) to do all that processing in the same place would be a REDUCTION of complexity. Allowing the processing to produce an intermediate object, say >>> key = dict(space=0, time=slice(None, 2)) would help here.
Real world examples are required, I think, to ground any discussions of complexity and simplicity. We want to optimise for what people do, for the problems they face. And this is a new feature.
We have a perfectly good way of handling keywords, so it is up to you to
explain why we shouldn't use it.
The scheme you support does not distinguish >>> d[1, 2, x=3, y=4] >>> d[(1, 2), x=3, y=4] I don't regard that as being perfectly good.
In addition, I would like >>> d = dict() >>> d[x=1, y=2] = 5 to work. It works out-of-the-box for my scheme. It can be made to work with a subclass of dict for the D'Aprano scheme.
I think that is enough for now.
I'd prefer to discuss this further by writing Python modules that contain code that can be tested. The testing should cover both the technical correctness and the user experience. To support this I intend not to focus on the next version of kwkey. https://pypi.org/project/kwkey/
-- Jonathan _______________________________________________ Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/3XRS7W... Code of Conduct: http://python.org/psf/codeofconduct/