On Fri, Oct 21, 2011 at 1:57 AM, raymond.hettinger <python-check...@python.org> wrote: > + If *typed* is set to True, function arguments of different types will be > + cached separately. For example, ``f(3)`` and ``f(3.0)`` will be treated > + as distinct calls with distinct results.
I've been pondering this one a bit since reviewing it on the tracker, and I'm wondering if we have the default behaviour the wrong way around. For "typed=True": - never results in accidental type coercion and potentially wrong answers* (see below) - cache uses additional memory (each entry is larger, more entries may be stored) - additional cache misses - differs from current behaviour For "typed=False" (current default): - matches current (pre-3.3) behaviour - can lead to accidental type coercion and incorrect answers I only just realised this morning that the existing (untyped) caching behaviour can give answers that are *numerically* wrong, not just of the wrong type. This becomes clear once we use division as our test operation rather than multiplication and bring Decimal into the mix: >>> from functools import lru_cache >>> @lru_cache() ... def divide(x, y): ... return x / y ... >>> from decimal import Decimal >>> 10 / 9 1.1111111111111112 >>> Decimal(10) / Decimal(9) Decimal('1.111111111111111111111111111') >>> divide(10, 9) 1.1111111111111112 >>> divide(Decimal(10), Decimal(9)) 1.1111111111111112 At the very least, I think lru_cache should default to typed behaviour in 3.3, with people being able to explicitly switch it off as a cache optimisation technique when they know it doesn't matter. You could even make the case that making the cache type aware under the hood in 3.2 would be a bug fix, and the only new feature in 3.3 would be the ability to switch off the type awareness to save memory. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com