Python's simplicity philosophy

[Dave Brueck]

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

And I disagree that that's necessarily a Good Thing. Good language design is
about finding that balance between general and specific. It's why I'm not a
language designer and it's also why I'm a Python user.

>  reduce() is more general and
> powerful than sum(), and would thus clearly be preferred by my
> mantra.

Yes, and eval() would clearly be preferred over them all.

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

I completely disagree - I see no evidence of that. We're looking at the same
data but drawing very different conclusions from it.

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

Not gonna happen - this _might_ happen if Python was a design-by-committee
language, but it's not.

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

'not quoting' != 'not following'
 and
'what gets debated on c.l.py' != 'what the Python developers do'

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

Not at all - I cut my teeth on 6502 assembly and there is plenty that I
still find clean, simple, and elegant about it, but it's horrible to program
in.

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

To you, perhaps. Not me, and not a lot of other people. To be honest I don't
really care that it's in the language. I'm not dying to see it get
deprecated or anything, but I do avoid it in my own code because it's
non-obvious to me, and if it were gone then Python would seem a little
cleaner to me.

Obviously what is intuitive to someone is highly subjective - I was really
in favor of adding a conditional operator to Python because to me it _is_
intuitive, clean, powerful, etc. because of my previous use of it in C. As
much as I wanted to have it though, on one level I'm really pleased that a
whole lot of clamoring for it did not result in its addition to the
language. I *like* the fact that there is someone making subjective
judgement calls, even if it means I sometimes don't get my every wish.

A good programming language is not the natural by-product of a series of
purely objective tests.

>  And taught in
> every CS curiculum.

Doubtful, and if it were universally true, it would weaken your point
because many people still find it a foreign or awkward concept. Besides,
whether or not something is taught in a CS program is a really poor reason
for doing anything.

-Dave