In article <52c94fec$0$29973$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@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. -- https://mail.python.org/mailman/listinfo/python-list