General question about Python design goals

[Paul Rubin]

Robert Kern <robert.kern at gmail.com> writes:
> Fine. Allow me to rephrase. Development is primarily motivated by
> practical needs and guided by notions of purity. 

That's bogus; if there was a discrepancy someone noticed and had to
work around, there's already been a practical failure, just not a
severe one.  Development should be guided by doing things right when
possible, making allowances for practical considerations that
sometimes call for compromise.  It's generally far better to do
something right the first time than to do something broken and have to
fix it later.  Those XP platitudes about prototyping and refactoring
are for when the program is still under development and the
requirements have not yet been discovered, and unfixed bogosity
affects just a few people (developers and testers).  When a program
has been declared finished and shipped to millions of users, any
bogosity remaining in it has a much larger effect, so bogosity should
be minimized.

> Use cases are the primary tool for communicating those practical
> needs. If you can't think of a single use case, what's the point of
> implementing something? Or rather, why should someone else implement
> it if you don't know how you would use it?

I can't think of a single use case for the addition (+) operator
working where either of the operands happens to be the number
0x15f1ef02d9f0c2297e37d44236d8e8ddde4a34c96a8200561de00492cb94b82 (a
random number I just got out of /dev/urandom).  I've never heard of
any application using that number, and the chances of it happening by
coincidence are impossibly low.  But if Python were coded in a way
that made the interpreter crash on seeing that number, I'd call that
a bug needing fixing.