> > With respect to implementation suggestions, numbers 1 2 and 3 definitely > > don't work for me. To extend the usage of items() without similarly > > extending the usage of keys() and values() would mean that we are > > special casing the items() function in a way that makes it inconsistant > > with the other dict functions. Number 5 seems too specific to me. I > > could live with 4 ;-) > > To quote the PEP: > """ > Alternatively, items() could simply let us control the (key, value) > order: > > (3) items(values_first=0) > """ > This suggestion No. 3 from the PEP does not special case the items() > function in a way that makes it "inconsistent with the other dict > functions" (i.e. keys(), values()); however it would suggest that > dict() then also ought take such an inverted, values-first list of > tuples if given an optional values_first parameter. But this IMHO > makes the dict() constructor too complicated, as well as having a > potential conflict with named keywords. In the sense that items() can still be used as before, it remains consistent. However since the same argument could be used to equally promote the modification of other dict functions to accept such arguments - such as keys(values_first=0) - to make the change to items() alone is (in my humble opinion) inconsistent. But that's just my opinion, others may feel differently.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4