Blog "about python 3"

[Roy Smith]

In article <52c94fec$0$29973$c3e8da3$5496439d at news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:

> How do we tell when software is buggy? We compare what it actually does to
> the promised behaviour, or expected behaviour, and if there is a
> discrepancy, we call it a bug. We don't compare it to some ideal that
> cannot be met. A bug report that math.pi does not have infinite number of
> decimal places would be closed as "Will Not Fix".

That's because it is inherently impossible to "fix" that.  But lots of 
bug reports legitimately get closed with "Will Not Fix" simply because 
the added value from fixing it doesn't justify the cost (whether in 
terms of development effort, or run-time resource consumption).

Go back to the package sorting example I gave.  If the sorting software 
mis-reads the address and sends my package to Newark instead of New York 
by mistake, that's clearly a bug.

Presumably, it's an error which could be eliminated (or, at least, the 
rate of occurrence reduced) by using a more sophisticated OCR algorithm.  
But, if those algorithms take longer to run, the overall expected value 
of implementing the bug fix software may well be negative.

In the real world, nobody cares if software is buggy.  They care that it 
provides value.