One potential issue with this approach just occurred to me. I apologise if my thinking on this is wrong.
Say a project implements __getitem__ with the signature
__getitem__(self, index, **kwargs)
Doesn't that mean that a "index" will not be an allowable index label, and that this conflict will depend on knowing the particular implementation details of the dunder methods?
On Mon, Aug 3, 2020, 13:43 Guido van Rossum email@example.com 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 firstname.lastname@example.org wrote:
On Mon, Aug 3, 2020, 13:11 Jonathan Fine email@example.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 See: https://www.python.org/dev/peps/pep-0472/
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. See: https://mail.python.org/pipermail/python-dev/2019-March/156693.html
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.
- Define 'o' and Protocol so that NOW gives the semantics you wish for.
- Extend Python so that FUTURE give the semantics you wish for.
- 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 See: https://firstname.lastname@example.org/message/YW3JXK...
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 -- 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/VCFLB4... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/