Elias, I'm a little confused about what you're suggesting. You want to have a Mapping that does not supply a keys method? What use case motivated your proposal?
On Mon, Sep 10, 2018, 7:04 PM Elias Tarhini <[email protected]> wrote: > This has been bouncing around in my head for a while regarding the > requisite keys() method on mappings: > > How come the ** unpacking operator, a built-in language feature, relies on > a non-dunder to operate? > > To me, I mean to say, requiring that classes implement keys() – a method > whose name is totally undistinguished – in order to conform to the mapping > protocol feels like a design running counter to Python's norm of using > dunders for everything "hidden". I am not sure if it feels dirty to anybody > else, however. Interestingly, the docs already say > <https://docs.python.org/3/reference/datamodel.html#object.__iter__> that > *[f]or > mappings, [__iter__()] should iterate over the keys of the container*, > but it of course is not enforced in any way at present. > > So, then — how about enforcing it? Should __iter__(), for the reasons > above, replace the current purpose of keys() in mappings? > > I'm not properly equipped at the moment to mess around with CPython > (sorry), but I assume at a minimum this would entail either replacing all > instances of PyMapping_Keys() with PyObject_GetIter() or alternatively > changing PyMapping_Keys() to call the latter. > > Does it sound like a reasonable change overall? > > Eli > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
