Python's simplicity philosophy

[Andrew Dalke]

Alex:
> I have already suggested, in a post on this thread's direct ancestor 9
days
> 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
would
> 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
min
> 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)
> somelist.sort(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)
and
 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
the form

  max(seq, **args)

But
  max(a, b, key=len)
seems reasonable as well.  Then again, so does
  max(seq, len)

> 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
 max(a, b)
and
 max(seq)
and allow a key function to be passed in, and make it feel
natural without running into problems when the two might be
mixed up.

> 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."

                    Andrew
                    dalke at dalkescientific.com