On Fri, 14 Aug 2020 at 11:07, Jonathan Fine <jfine2...@gmail.com> wrote:
> NO ARGUMENTS > > I'd like d[] to become valid syntax. This makes me a bit uncomfortable. > SEMANTICS OF NO ARGUMENTS > I can see two basic ways of allowing no arguments. One is for the interpreter > to construct an object that is the argument passed to __getitem__ and so > forth. The other is to not pass an argument at all. I see this as a secondary > question. I understand it makes sense if you assume that you can have default arguments. but still it's kind of weird. and it's not always obvious how each structure is going to implement it. > NO POSITIONAL ARGUMENTS > I'd like > >>> d[x=1, y=2] > to be valid syntax. It's not clear to me that all agree with this. Even if > there are no objections, I'd like positive confirmation. Yes, it should be. > CONSEQUENCE > Suppose > >>> d[x=1, y=2] > is valid syntax. If so, then there is I think consensus that > >>> d[x=1, y=2] = 42 > >>> d[x=1, y=2] > 42 > can be implemented, where d is an instance of a suitable class. Otherwise, > what's the point? Yes. Agreed. > QUESTION > Suppose we have > >>> d[x=1, y=2] = 42 > >>> d[x=1, y=2] > 42 > where d is an instance of a suitable class X that has no special knowledge of > keywords. Initially, when I wrote the pep, the idea was that there was no distinction of kwargs and normal args. Basically the idea was that currently the only "metainfo" associated to every argument is purely positional (e.g. the meaning of position 1 is implicit). But index 1 can have a specific semantic meaning (e.g. it could be a day). So in practice they would be one and the same, just that you add non-positional semantic meaning to indexes, and you can refer to them either through the position, or this additional semantic meaning. In other words, if you claim that the first index is day, and the second index is detector, somehow, there is no difference between these d[3, 4] d[day=3, detector=4] d[detector=4, day=3] In fact, my initial feeling would be that you can use either one or the other. You should not be able to mix and match. the pep went through various revisions, and we came to a possible proposal, but it's not set in stone. > In other words, we also have for example > >>> d[a='alpha', g='gamma', z=12] = 'cheese' > >>> d[a='alpha', g='gamma', z=12] > 'cheese' > > My question is this: Should such a class > >>> X = type(d) > be part of standard Python, as part of PEP 472? (My answer is: Yes, it should > be in standard Python.) Yes and no. In my opinion, the current classes (e.g. dict) *may* be extended to support this (optional) functionality. But the target should probably be something like numpy or pandas, or any other class that wants the flexibility for a named index approach. I would not add X to python stdlib. -- Kind regards, Stefano Borini _______________________________________________ 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/BEVAR5LB5SN66RBR7DRAHSBWMHUUKLSJ/ Code of Conduct: http://python.org/psf/codeofconduct/
