I wasn't saying you had agreed to anything, I was saying you requested that others agree on an API before trying to implement a prototype of it ("It would help if someone looked into a prototype implementation as well (once a design has been settled on).").  

Jonathan seems to be going ahead with his own API (using a new class to hold all indexes, named or otherwise), which most people who commented didn't seem to like.  

On Mon, Aug 3, 2020, 13:43 Guido van Rossum <guido@python.org> wrote:
I haven't agreed to anything. Though last time I thought about this I was in favor of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into `x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__` would do with that is a different issue -- probably it would be an error.

On Mon, Aug 3, 2020 at 10:32 AM Todd <toddrjen@gmail.com> wrote:
On Mon, Aug 3, 2020, 13:11 Jonathan Fine <jfine2358@gmail.com> wrote:
SUMMARY:
Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.

This package is about PEP 472 -- Support for indexing with keyword arguments

As a result, I think we're now in a good position to try this idea out, using present day Python. This includes building some clients that can use the new feature, should it become available. It also includes exploring the design of the API.

The crucial idea is writing
    >>> from kwkeys import o
    >>> d[o(1, 2, a=3, b=4)]
as a stopgap, until
    >>> d[1, 2, a=3, b=4]
is available.

If you're interested, please do try it out.

IN MORE DETAIL:

On 3 May 2020, Andras Tontas reopened discussion of the PEP. This PEP was created in June 2014, and closed in March 2019, due to lack of interest.

This time round, things went better. On 16 July, Guido wrote (substitute PEP for PRP)

I think it’s a reasonable idea and encourage you to start working on a
design for the API and then a PRP. It would help if someone looked into a
prototype implementation as well (once a design has been settled on).

Later on 16 July, I wrote
I'll now state some goals.
 
1. Define 'o' and Protocol so that NOW gives the semantics you wish for.
2. Extend Python so that FUTURE give the semantics you wish for.
3. And the NOW syntax continues to work as expected (without changing 'o' and Protocol).
4. And all current use of container[key] continues to work as before.
 
I believe that it is possible to achieve these goals. My previous posts to this discussion outline some of the key ideas. My next step, when I have time, is to implement and publish general purpose code for the NOW part of this list of goals.
  
On 18 July I wrote that by the end of July I would implement and publish general purpose code for the NOW part of these goals

Earlier today, 3 days overdue, I fulfilled my commitment. I hope it helps some of you, and does no harm to others.
-- 
Jonathan


Do we have an agreement on the API as Guido requested?  From my understanding, and please correct me if I am wrong, you are still talking about implementing this using a new class.  However, most people who support the use of labelled indexing.and expressed an opinion support a keyword argument-based approach.  
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/VCFLB4RPZ2HERAXKCRAJYITKQTWUOIYO/
Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido van Rossum (python.org/~guido)