Python's simplicity philosophy
adalke at mindspring.com
Sun Nov 16 20:16:22 CET 2003
> I have already suggested, in a post on this thread's direct ancestor 9
> ago, the 100%-equivalent substitution in pure, simple, faster Python:
I've only been skimming this thread. Now upon reread I see you also
looked at the standard library. No fair -- I'm supposed to be the only
one who does that! :)
> Nope -- itertools is not about CONSUMERS of iterators, which this one
> be. All itertools entries RETURN iterators.
Yup. There's no good, existing, natural place for such a function, that
I can tell.
> Given that the sort method of lists now has an optional key= argument, I
> think the obvious approach would be to add the same optional argument to
> and max with exactly the same semantics. I.e., just as today:
That follows Moshe's comment that a "Decorate Max Undecorate",
in parallel to Decorate Sort Undecorate. Nice.
> we'd also have
> x = max(somelist, key=whatever)
> assert x == somelist[-1]
Is 'key' also an iterable? ...
> That would be max(seq, key=len) in my proposal.
Ahh, it's the function used to get the keys. What about 'getkey'
as a name?
I looked through the back thread but didn't see your function
definition. Is it backwards compatible to the existing max
function?... You know, I never realized how strange max was
in the first place, so that
max( (1, 2) )
are both valid. It must assume that if there's only one argument
then the latter form is appropriate. Then your form must say
that if there's only one non-keyword argument then it's of
max(a, b, key=len)
seems reasonable as well. Then again, so does
> a perfectly natural extension, it seems to me. I've found such total and
> extreme opposition to this perfectly natural extension in private
> correspondence about it with another Python committer that I've so far
> delayed proposing it on python-dev -- for reasons that escape me it would
> appear to be highly controversial rather than perfectly obvious.
My guess is that reaction is based on the need to have both forms
and allow a key function to be passed in, and make it feel
natural without running into problems when the two might be
> even though
> the tasks handled by the standard library are heavily slanted
> to string and text processing, networking &c, and (of course)
> "pure infrastructure", rather than typical application tasks.
Yeah, I worry about that bias error when I do my analysis.
I really should also scan some of the other (proprietary) code
bases I have access to, but then it leads to claims of being
irreproducible. Besides, despite being a scientific programmer,
I mostly do "string and text processing, networking &c."
dalke at dalkescientific.com
More information about the Python-list