The dict keys method has other benefits beyond iteration. For example, it provides a set-like interface.
On Wed, Sep 12, 2018, 10:50 PM Elias Tarhini <[email protected]> wrote: > On Wed, Sep 12, 2018 at 4:42 PM Michael Selik <[email protected]> wrote: > >> You want to have a Mapping that does not supply a keys method? What use >> case motivated your proposal? >> > > Yes, my proposal was to consider allowing __iter__() to subsume keys() > entirely, for the reasons outlined in my second email -- which I'm just > realizing was an accidental "reply one" to Alex Walters rather than a > "reply all", yikes! Here it is, duplicated: > > Ahh, no, I phrased my question a bit badly -- I'm not proposing that the >> keys() method be *removed* from what it exists on currently, but rather >> that this: >> >> > To be treated like a mapping everywhere, python requires that you >> define* a keys() method, so why not use it? >> >> be changed, such that only __iter__() and __getitem__() indicate a >> mapping rather than keys() and the same. The latter method would then be >> optional, but not necessarily removed from the front-facing API. >> >> Granted, my only strong argument is that the ** unpacking operator >> depends on this method to do its job, and it's currently alone amongst >> Python's operators in depending on a non-dunder to do so; that, combined >> with the point heading the below paragraph, is also why I'm only going >> after keys() — not items() or sequences' index() or any of the other >> normally-named-but-important methods. >> >> And given that __iter__() is already recommended to iterate over a >> mapping's keys, it doesn't seem illogical to me to just let it take that >> job officially (and in turn, I guess, to make keys() on stdlib/built-in >> types just return __iter__()). I don't believe there would be another >> expected use for it in a mapping, anyway, correct? (I haven't done the >> research here, but there could be third-party authors who use it to iterate >> over items(), given that “why does it iterate over just keys” a >> somewhat-recognizable discussion topic on such beginner forums as >> /r/learnpython... if so, this could be a good opportunity to >> force-standardize that behavior as well.) >> >> Does this clarify my intent? ...I don't doubt that there are roadblocks >> I'm still ignoring, though. >> >> Eli >> > > However, Serihy's example of {**[0, 2, 1]} is so-plainly irreconcilable > -- somewhat embarrassing for me to have missed it -- that I'm now > reluctantly no longer in favor. (Well, really, I'm tempted to say *why > not?*, but I do see that it wouldn't be a good thing overall.) > And I still kind of feel that there should be a dunder involved somewhere > in this, but nowhere near strongly enough to dispute that *"[t]he dunder > methods are dunder methods because they are not generally directly useful. > [There doesn't seem to be] a major problem with having the mapping api call > keys() [...]"*, as it's reasonable and rationalizes the current system > well enough. Thank you for bearing with ;) > > > Eli > > On Wed, Sep 12, 2018 at 4:42 PM, Michael Selik <[email protected]> wrote: > >> 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/
