On Thu, 27 Aug 2020 at 03:00, Steven D'Aprano <st...@pearwood.info> wrote:
> > To me, most of the discussion is being derailed in deciding how this > > should look like on the __getitem__ end and how to implement it, but > > we haven't even decided what it should look like from the outside > > Is that even a question? > > obj[index, keyword=value] > > where index is any comma-separated list of expressions, including > slices, keyword is an identifier, and value is any expression including > slices. Are there even any other options being considered? Well, there are a lot of corner cases, such as what to do with obj[]. We already discussed it and we both agreed that it was a bad idea to allow it. Plus there's no consensus, as far as I can tell, if the index and the keyword should interact or not. I say they should, but others say they should not. With interact I mean that anonymous axes exist and live an independent life from named axes, and this behavior is different from function call, where you always give names to arguments on the function declaration side (unless you have *args, of course). > - You can have multiple keyword=value pairs, separated by commas. They > must all follow the index part. Duplicate keywords is a runtime error, > just as they are are for function calls. > > - An empty subscript remains a syntax error, even if the method > signature would allow it. > All right. So we agree on that. I wanted to be sure that we were not excluding at all the possibility to do _either_ no keyword _or_ only keywords. We do want to allow mixing. So now the question is what to do with the mixing. > > (although it's probably in the massive number of emails I am trying to > > aggregate in the new PEP). > > As PEP author, you don't have to include every little tiny detail of > every rejected idea. It should be a summary, and it is okay to skip over > brief ideas that went nowhere and just point back to the thread. > > One of the weaknesses, in my opinion, of the existing PEP is that it > tries to exhaustively cover every possible permutation of options (and > in doing so, managed to skip the most useful and practical option!). Completely agree with your observation. The main problem when I wrote it is that there was no consensus. I had my preference, the other author had a different one, and the mailing list also didn't settle on a plausible, dead sure implementation. We were as confused back then as we are today. > So my advise is: choose the model you want, and write the PEP to > persuade that is the best model, why the others fail to meet the > requirements. I really hope the model you choose is the one I describe > above, in which case I will support it, but if you hate that model and > want something else that's your right as the PEP author. Will do. > (Although the earlier co-authors may no longer wish to be associated > with the PEP if you change it radically.) I lost contact with the other author. I haven't heard of him since, even on the mailing list. -- 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/DNHM3A36JMXQS6EHBYRVMTADZN62OD6J/ Code of Conduct: http://python.org/psf/codeofconduct/
