Python's simplicity philosophy
dave at pythonapocrypha.com
Tue Nov 11 23:32:37 CET 2003
> >> 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
> > (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
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'
'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
> > 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
> > correct. Correspondingly, when you read someone else's Python code that
> > some feature you're not familiar with, odds are in your favor that
> > 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
> > And that is why I wouldn't be sad if reduce() were to disappear - I
> > use reduce() and _anytime_ I see reduce() in someone's code I have to
> > way down and sort of rehearse in my mind what it's supposed to do and
> > 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.
More information about the Python-list