Python's simplicity philosophy

[Alex Martelli]

Andrew Dalke wrote:

> 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!  :)

On python-dev one had better make ready by such a preliminary check
for the inevitable objections.


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

I agree.  Which is why I've been claiming that we need a module of
"iterator consumers" (accumulators?) in 2.4 to get full advantage
from the new genexp's and itertools enhancements.


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

Hadn't seen Moshe comment on it, but, yes, it IS the same idea.


>> we'd also have
>>
>> x = max(somelist, key=whatever)
>> somelist.sort(key=whatever)
>> assert x == somelist[-1]
> 
> Is 'key' also an iterable? ...

No, a callable (just like in 2.4's sort).


>> 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?

See my comments to Bengt on this thread.  Summarizing: 2.4 is in
pre-alpha, therefore suggestions to change it will be quite
appropriate on python-dev.  The name and semantics of such an
optional argument must of course be the same as whatever ends up
being accepted for lists' sort method (currently, it's key=).


> 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

Yes:

>>> max(23)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iteration over non-sequence


> 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)

max(seq, len) must of course remain compatible with today.  Keyword
arguments are handled separately (in built-in functions).


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

Interestingly enough, this objection wasn't raised.  If it were,
then it would easily be squashed by analogy with somelist.sort:
somelist.sort(foo) must mean to use foo as the comparator func,
for backwards compatibility, so that one MUST give the argument
name, somelist.sort(key=foo), to use a key-extracting func instead.


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

A corpus of freely available code from the Vaults of Parnassus
might make for a useful resource for such tasks.


Alex