On Sun, Jan 5, 2014 at 12:55 AM, Roy Smith <r...@panix.com> wrote: > In article <mailman.4882.1388808283.18130.python-l...@python.org>, > Mark Lawrence <breamore...@yahoo.co.uk> wrote: > >> Surely everybody prefers fast but incorrect code in >> preference to something that is correct but slow? > > I realize I'm taking this statement out of context, but yes, sometimes > fast is more important than correct. Sometimes the other way around.
More usually, it's sometimes better to be really fast and mostly correct than really really slow and entirely correct. That's why we use IEEE floating point instead of Decimal most of the time. Though I'm glad that Python 3 now deems the default int type to be capable of representing arbitrary integers (instead of dropping out to a separate long type as Py2 did), I think it's possibly worth optimizing small integers to machine words - but mainly, the int type focuses on correctness above performance, because the cost is low compared to the benefit. With float, the cost of arbitrary precision is extremely high, and the benefit much lower. With Unicode, the cost of perfect support is normally seen to be a doubling of internal memory usage (UTF-16 vs UCS-4). Pike and Python decided that the cost could, instead, be a tiny measure of complexity and actually *less* memory usage (compared to UTF-16, when lots of identifiers are ASCII). It's a system that works only when strings are immutable, but works beautifully there. Fortunately Pike doesn't have any, and Python has only one, idiot like jmf who completely misunderstands what's going on and uses microbenchmarks to prove obscure points... and then uses nonsense to try to prove... uhh... actually I'm not even sure what, sometimes. I wouldn't dare try to read his posts except that my mind's already in a rather broken state, as a combination of programming and Alice in Wonderland. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
