How should contextmanager/ContextDecorator work with generators?

[anntzer]

BPO	37743
Nosy	@ncoghlan

^{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 = None
closed_at = None
created_at = <Date 2019-08-01.23:33:04.730>
labels = ['3.8', 'docs']
title = 'How should contextmanager/ContextDecorator work with generators?'
updated_at = <Date 2019-09-03.10:21:10.928>
user = 'https://github.com/anntzer'

bugs.python.org fields:

activity = <Date 2019-09-03.10:21:10.928>
actor = 'Antony.Lee'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2019-08-01.23:33:04.730>
creator = 'Antony.Lee'
dependencies = []
files = []
hgrepos = []
issue_num = 37743
keywords = []
message_count = 2.0
messages = ['348878', '351074']
nosy_count = 1.0
nosy_names = ['ncoghlan']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue37743'
versions = ['Python 3.8']

[anntzer]

The docs for ContextDecorator (of which contextmanager is a case) describe its semantics as:

... for any construct of the following form:

    def f():
        with cm():
            # Do stuff

ContextDecorator lets you instead write:

    @cm()
    def f():
        # Do stuff

However, when decorating a generator, the equivalence is broken:

    from contextlib import contextmanager

    @contextmanager
    def cm():
        print("start")
        yield
        print("stop")

    def gen_using_with():
        with cm():
            yield from map(print, range(2))

    @cm()
    def gen_using_decorator():
        yield from map(print, range(2))

    print("using with")
    list(gen_using_with())
    print("==========")
    print("using decorator")
    list(gen_using_decorator())

results in

using with
start
0
1
stop
\==========
using decorator
start
stop
0
1

i.e., when used as a decorator, the entire contextmanager is executed first before iterating over the generator (which is unsurprising given the implementation of ContextDecorator: ContextDecorator returns a function that executes the context manager and returns the generator, which is only iterated over later).

Should this be considered as a bug in ContextDecorator, and should ContextDecorator instead detect when it is used to decorate a generator (e.g. with inspect.isgeneratorfunction), and switch its implementation accordingly in that case?

[ncoghlan]

This is a documentation bug, as the current behaviour is as intended, but the documented equivalence doesn't hold for generator functions: for a generator function, the CM will only be applied when the generator is instantiated, whereas the inline context manager version will be held open until the generator is closed or destroyed.

That said, an approach similar to the one discussed in bpo-37398 could also be applied, here, with a separate "ContextDecorator.generator()" class method added to give the "wrapped yield from" behaviour. If anyone is interested in pursuing that, it can be filed as a separate enhancement issue (leaving this bug to cover the fact that the existing documentation is only accurate for regular synchronous functions)