[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: New changeset 0367a36fdc36b9c909c4d5acf7cde6ceeec0ba69 by Mark Shannon in branch 'main': bpo-43683: Streamline YIELD_VALUE and SEND (GH-30723) https://github.com/python/cpython/commit/0367a36fdc36b9c909c4d5acf7cde6ceeec0ba69 --

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- pull_requests: +28914 pull_request: https://github.com/python/cpython/pull/30723 ___ Python tracker ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: Yes, most of it :) We haven't implemented points 2 and 3, yet. I'm in no hurry to implement 3. It would clean up `gen.throw` a lot, and break the dependency between that code and the interpreter, but it isn't urgent. 2 is more urgent. I think we need it to

[issue43683] Handle generator (and coroutine) state in the bytecode.

Pablo Galindo Salgado added the comment: Is there anything left here? -- priority: release blocker -> ___ Python tracker ___ ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

Pablo Galindo Salgado added the comment: > This is quite an obscure bug, so I'm not sure that it is worth blocking the > release for. But I'm not the release manager :) Well, it certainly didn't block 3.10.1 or 3.11.0a3 ;) -- ___ Python tracker

[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: Sorry about the delay; this dropped off my list. I'll fix it shortly. This is quite an obscure bug, so I'm not sure that it is worth blocking the release for. But I'm not the release manager :) -- ___ Python

[issue43683] Handle generator (and coroutine) state in the bytecode.

Pablo Galindo Salgado added the comment: Unfortunately, this has not been fixed into 3.10.1 and 3.11.0a3 as this hasn't version information and therefore has missed our automatic checks for blockers. I have marked https://bugs.python.org/issue46009? as release blocker, as well as this issue

[issue43683] Handle generator (and coroutine) state in the bytecode.

Dennis Sweeney added the comment: bpo-46009 about the same behavior change -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue43683] Handle generator (and coroutine) state in the bytecode.

Pablo Galindo Salgado added the comment: Mark, is something left in this issue? -- nosy: +pablogsal ___ Python tracker ___ ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

Damien George added the comment: Thanks for confirming the bug. Sending non-None to a not-started generator could arguably be case (2), because that's exactly the semantics introduced by the commit that broke the test case :) Honestly I don't have a strong opinion on which way this goes.

[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: Just to be clear, it is the behavior change that should be reverted, not necessarily the new bytecode. In fact we should probably push on with (2) and add an exception handler wrapping the whole generator except the GEN_START. That way a GEN_START exception

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: Damien, thanks for catching this. The change was not intended. There are two kind of exceptions raised by send. 1. Where a pre-condition is not met, e.g. a generator is already ruuning (caller errors) 2. When the generator/coroutine raises an exception

[issue43683] Handle generator (and coroutine) state in the bytecode.

Damien George added the comment: It looks like this change introduced a subtle, and maybe intended (?), behavioural change. Consider (from MicroPython's test suite): def f(): n = 0 while True: n = yield n + 1 print(n) g = f() try: g.send(1) except TypeError:

[issue43683] Handle generator (and coroutine) state in the bytecode.

Dennis Sweeney added the comment: Looks like we both opened PRs in the same minute. The MAGIC constant didn't get updated, but perhaps that can just be included in the Minor Corrections PR. I'd bet a CI check could be added to check that if the opcodes change then

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Dennis Sweeney : -- nosy: +Dennis Sweeney nosy_count: 1.0 -> 2.0 pull_requests: +23962 pull_request: https://github.com/python/cpython/pull/25225 ___ Python tracker

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- pull_requests: +23961 pull_request: https://github.com/python/cpython/pull/25224 ___ Python tracker ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

Mark Shannon added the comment: New changeset b37181e69209746adc2119c471599a1ea5faa6c8 by Mark Shannon in branch 'master': bpo-43683: Handle generator entry in bytecode (GH-25138) https://github.com/python/cpython/commit/b37181e69209746adc2119c471599a1ea5faa6c8 --

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- pull_requests: +23885 pull_request: https://github.com/python/cpython/pull/25138 ___ Python tracker ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- keywords: +patch pull_requests: +23884 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25137 ___ Python tracker

[issue43683] Handle generator (and coroutine) state in the bytecode.

Change by Mark Shannon : -- assignee: -> Mark.Shannon stage: -> needs patch type: -> performance ___ Python tracker ___ ___

[issue43683] Handle generator (and coroutine) state in the bytecode.

New submission from Mark Shannon : Every time we send, or throw, to a generator, the C code in genobject.c needs to check what state the generator is in. This is inefficient and couples the generator code, which should just be a thin wrapper around the interpreter, to the internals of the