Python's simplicity philosophy

[Douglas Alan]

"Dave Brueck" <dave at pythonapocrypha.com> writes:

>> Of course I am not joking.  I see no good coming from the mantra, when
>> the mantra should be instead what I said it should be:

>> "small, clean, simple, powerful, general, elegant"

> It's really a matter of taste - both "versions" mean about the same to me
> (and to me both mean "get rid of reduce()" ;-) ).

No, my mantra plainly states to keep general and powerful features
over specific, tailored features.  reduce() is more general and
powerful than sum(), and would thus clearly be preferred by my
mantra.

The mantra "there should be only one obvious way to do it" apparently
implies that one should remove powerful, general features like
reduce() from the language, and clutter it up instead with lots of
specific, tailored features like overloaded sum() and max().  If so,
clearly this mantra is harmful, and will ultimately result in Python
becoming a bloated language filled up with "one obvious way" to solve
every particular idiom.  This would be very bad, and make it less like
Python and more like Perl.

I can already see what's going to happen with sum(): Ultimately,
people will realize that they may want to perform more general types
of sums, using alternate addition operations.  (For intance, there may
be a number of different ways that you might add together vectors --
e.g, city block geometry vs. normal geometry.  Or you may want to add
together numbers using modular arithmetic, without worrying about
overflowing into bignums.)  So, a new feature will be added to sum()
to allow an alternate summing function to be passed into sum().  Then
reduce() will have effectively been put back into the language, only
its name will have been changed, and its interface will have been
changed so that everyone who has taken CS-101 and knows off the top of
their head what reduce() is and does, won't easily be able to find it.

Yes, there are other parts of The Zen of Python that point to the
powerful and general, rather than the clutter of specific and
tailored, but nobody seems to quote them these days, and they surely
are ignoring them when they want to bloat up the language with
unneccessary features like overloaded sum() and max() functions,
rather than to rely on trusty, powerful, and elegant reduce(), which
can easily and lightweightedly do everything that overloaded sum() and
max() can do and quite a bit more.

>> To me, there is never *one* obviously "right way" to do anything

> Never? I doubt this very much. When you want to add two numbers in a
> programming language, what's your first impulse? Most likely it is
> to write "a + b".

Or b + a.  Perhaps we should prevent that, since that makes two
obviously right ways to do it!

> Having said that though, part of the appeal of Python is that it hits the
> nail on the head surprisingly often: if you don't know (from prior
> experience) how to do something in Python, your first guess is very often
> correct. Correspondingly, when you read someone else's Python code that uses
> some feature you're not familiar with, odds are in your favor that you'll
> correctly guess what that feature actually does.

All of this falls out of "clean", "simple", and "elegant".

> And that is why I wouldn't be sad if reduce() were to disappear - I don't
> use reduce() and _anytime_ I see reduce() in someone's code I have to slow
> way down and sort of rehearse in my mind what it's supposed to do and see if
> I can successfully interpret its meaning (and, when nobody's looking, I
> might even replace it with a for-loop!).

C'mon -- all reduce() is is a generalized sum or product.  What's
there to think about?  It's as intuitive as can be.  And taught in
every CS curiculum.  What more does one want out of a function?

|>oug