Generators with lru_cache can be non-intuituve

[exhuma]

BPO	33827
Nosy	@rhettinger, @serhiy-storchaka, @exhuma

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/rhettinger'
closed_at = <Date 2018-06-12.05:25:46.073>
created_at = <Date 2018-06-11.07:16:13.017>
labels = ['type-bug', 'invalid']
title = 'Generators with lru_cache can be non-intuituve'
updated_at = <Date 2018-06-12.05:25:46.072>
user = 'https://github.com/exhuma'

bugs.python.org fields:

activity = <Date 2018-06-12.05:25:46.072>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2018-06-12.05:25:46.073>
closer = 'rhettinger'
components = []
creation = <Date 2018-06-11.07:16:13.017>
creator = 'exhuma'
dependencies = []
files = []
hgrepos = []
issue_num = 33827
keywords = []
message_count = 3.0
messages = ['319279', '319281', '319363']
nosy_count = 3.0
nosy_names = ['rhettinger', 'serhiy.storchaka', 'exhuma']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33827'
versions = []

[exhuma]

Consider the following code:

# filename: foo.py

    from functools import lru_cache


    @lru_cache(10)
    def bar():
        yield 10
        yield 20
        yield 30


    # This loop will work as expected
    for row in bar():
        print(row)

    # This loop will not loop over anything.
    # The cache will return an already consumed generator.
    for row in bar():
        print(row)

This behaviour is natural, but it is almost invisible to the caller of "foo".

The main issue is one of "surprise". When inspecting the output of "foo" it is clear that the output is a generator:

    >>> import foo
    >>> foo.bar()
    <generator object bar at 0x7fbfecb66a40>

**Very** careful inspection will reveal that each call will return the same generator instance.

So to an observant user the following is an expected behaviour:

    >>> result = foo.bar()
    >>> for row in result:
    ...    print(row)
    ...
    10
    20
    30
    >>> for row in result:
    ...     print(row)
    ...
    >>>

However, the following is not:

    >>> import foo
    >>> result = foo.bar()
    >>> for row in result:
    ...     print(row)
    ...
    10
    20
    30
    >>> result = foo.bar()
    >>> for row in result:
    ...     print(row)
    ...
    >>>

Would it make sense to emit a warning (or even raise an exception) in lru_cache if the return value of the cached function is a generator?

I can think of situation where it makes sense to combine the two. For example the situation I am currently in:

I have a piece of code which loops several times over the same SNMP table. Having a generator makes the application far more responsive. And having the cache makes it even faster on subsequent calls. But the gain I get from the cache is bigger than the gain from the generator. So I would be okay with converting the result to a list before storing it in the cache.

What is your opinion on this issue? Would it make sense to add a warning?

[serhiy-storchaka]

No, this will break cases when you need to cache generators.

There are many ways of using lru_cache improperly, and we can't distinguish incorrect uses from intentional correct uses.

[rhettinger]

Serhiy is correct. In general, there is no way to detect when someone is caching something that should be cached (i.e. impure functions).