[Python-Dev] [Python-checkins] cpython: Issue 13227: Option to make the lru_cache() type specific (suggested by Andrew
Nick Coghlan
ncoghlan at gmail.com
Sat Oct 22 01:31:53 CEST 2011
On Fri, Oct 21, 2011 at 1:57 AM, raymond.hettinger
<python-checkins at 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list