Robert Kern <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
