On Mon, 13 Sep 2004 11:34:06 +1000, David Harrison
<dave.l.harrison at gmail.com> wrote:
>
> With regards to the two arguments put forward by Grant, the first - that
> it is an idiom known only to experienced campaigners - does not seem to
> be a supportable argument to me. I think the problem has quite a
> simple elegant solution which is rather easily discovered - there are
> lots of differences in Python that require an inexperienced programmer
> to learn a new idiom (such as the looping construct).
And of course, it is better to teach these idioms to newbies so they
become competent. A python newbie will be much better off if they
learn the decorate, sort, [undecorate] idiom and list comprehensions,
neither of which are particularly difficult; and both will serve the
newbie well in many other areas.
> 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.
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