On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine <jfine2...@gmail.com> wrote:
> Todd 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-names > >>> 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. rain[time=0:12, location=location] > 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 -- 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/3XRS7WVSFJAZJ6TODL62KZYEDRUV3CRI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Sebastian Kreft
_______________________________________________ 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/766LV6UK6NJBXBS43K52HGIGBUE5W5I3/ Code of Conduct: http://python.org/psf/codeofconduct/
