General question about Python design goals

[Mike Meyer]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
> Mike Meyer <mwm at mired.org> writes:
>> > An awful lot of the time in this newsgroup, "practicality beats
>> > purity" translates as "the programmer can just be a lazy slob".
>> You post that as if it were a bad thing.
> Yes.  The idea of using a program that someone else wrote, is that
> they do the work so I don't have to.  If their doing less work means
> that I have to do more, the program isn't as good as it might be.

No, it's not as good *for your purpose* as it might be. But they
didn't write it for your purpose, they wrote it for theirs. The latter
is really the only standard of judgement.

> A program like Python intended for wide distribution and use by large
> numbers of people whose needs aren't known in advance, should do as
> much to help its users as development resources allow.

True. You seem to disagree about how they choose to allocate the
resources. The fix for that is well-known.

> Are you familiar with R. Gabriel's piece "Worse is better"?  That's
> not what I see "practicality beats purity" as being intended to mean.

Why not? That seems to summarise a couple of the points in the more
successful design philosophy, most notably:

    The design most not be overly inconsistent.
    The design must cover as many important situations as is practical.

If these don't reflet what you think "Practicality beats purity"
means, then what do you think it means?

Actually, I've been thinking about that bit recently, and noting that
a number of things from "import this" seem to espouse the more
successful approach from that section:

Simple is better than complex.
Complex is better than complicated.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.

>> > If following POLA costs that much, at least in the kinds of examples
>> > we talk about all the time here, something is probably wrong with the
>> > implementation (or the design) to begin with.
>> True, but not constructive. Knowing that something is wrong is
>> easy. Diagnosing the problem is harder. Curing it is even harder.
> Look at the list.count() example at the start of this thread.
> Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> Python by an order of magnitude. 

Did somebody actually use "Practicality beats purity" as an excuse for
not making list.count and string.count have the same arguments? If so,
I missed it. I certainly don't agree with that - count ought to work
right in this case.

> A suitably factored implementation might handle lists and strings
> with the exact same code and not incur any extra cost at all.  That
> type of thing happens all the time here.

If it happens all the time, you shouldn't have any trouble nameing a
number of things that a majority of users think are misfeatures that
aren't being fixed. Could you do that?

   <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.