[Python-announce] TatSu 5.10.2 - PEG parser generator

竜 TatSu is a tool that takes grammars in a variation of EBNF as input, and outputs memoizing (Packrat) PEG parsers in Python. Please take a look at the release log for the latest improvements and fixes: https://github.com/neogeny/TatSu/releases -- Juancarlo Añez mailto:apal...@gmail.com

[Python-announce] TatSu v5.9.0 - PEG parser generator

竜 TatSu is a tool that takes grammars in a variation of EBNF as input, and outputs memoizing (Packrat) PEG parsers in Python. Why use a PEG parser? Because regular languages (those parsable with Python's `re` package) "cannot count". Any input with nested structures or with balancing of

Re: Using generator expressions

On Tue, 26 Sept 2023 at 01:39, Jonathan Gossage via Python-list wrote: > > Many thanks, all. It turned out that my problem was not fully understanding > the use and power of the unpack operator *. Using it to activate my > generator made things start to work. I changed the line whe

Re: Using generator expressions

Many thanks, all. It turned out that my problem was not fully understanding the use and power of the unpack operator *. Using it to activate my generator made things start to work. I changed the line where I invoked the generator to: y = test1(*(a for a in st)) adding the unpack operator

Re: Using generator expressions

On 9/25/2023 10:15 AM, Jonathan Gossage via Python-list wrote: I am having a problem using generator expressions to supply the arguments for a class instance initialization. The following example shows the problem: class test1(object): def __init__(self, a, b): self.name

Re: Using generator expressions

y = test1(*[a for a in st]) y = test1(*st) Maybe any of these would be ok for you? Regards, DG > On 25 Sep 2023, at 17:15, Jonathan Gossage via Python-list > wrote: > > I am having a problem using generator expressions to supply the arguments > for a class instance

Using generator expressions

I am having a problem using generator expressions to supply the arguments for a class instance initialization. The following example shows the problem: class test1(object): def __init__(self, a, b): > self.name = a self.value = b st = 'Programming Renaissance, Any'.sp

Re: Creating lambdas inside generator expression

On 29/06/2022 23:17, Chris Angelico wrote: On Thu, 30 Jun 2022 at 02:49, Johannes Bauer wrote: But now consider what happens when we create the lambdas inside a list comprehension (in my original I used a generator expresison, but the result is the same). Can you guess what happens when we

Re: Creating lambdas inside generator expression

On Thu, 30 Jun 2022 at 02:49, Johannes Bauer wrote: > But now consider what happens when we create the lambdas inside a list > comprehension (in my original I used a generator expresison, but the > result is the same). Can you guess what happens when we create conds > like thi

Re: Creating lambdas inside generator expression

scode("foo"), lambda msg: msg.hascode("bar"), ] msg = Msg() print(conds[0](msg)) print(conds[1](msg)) It works perfectly and does exactly what it looks like. The output is: Check for foo False Check for bar False But now consider what happens when we create the lambdas ins

Creating lambdas inside generator expression

utput is: Check for foo False Check for bar False But now consider what happens when we create the lambdas inside a list comprehension (in my original I used a generator expresison, but the result is the same). Can you guess what happens when we create conds like this? conds = [ lambda msg: msg.ha

Re: Creating lambdas inside generator expression

print(conds[1](msg)) > > > > It works perfectly and does exactly what it looks like. The output is: > > Check for foo > False > Check for bar > False > > But now consider what happens when we create the lambdas inside a list > comprehension (in my original

[issue500078] Add built-in generator factory function

Change by admin : -- github: None -> 35872 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue510373] Make generator factory a type name

Change by admin : -- github: None -> 35995 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue490939] .join(generator) crash bug

Change by admin : -- github: None -> 35705 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue448835] Python 2.2a1 Under Idle - Generator

Change by admin : -- github: None -> 34912 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45963] Embed interpreter frame in generator.

STINNER Victor added the comment: Leak fixed by: commit 064e53d19aea6d6906fa8f7706a2556a2c293ccd Author: Mark Shannon Date: Tue Dec 7 18:05:48 2021 + Fix leak when an exception is raised during generator creation. (GH-29960) -- nosy: +vstinner

[issue42760] inspect.iscoroutine returns False for asynchronous generator methods

Change by Andrew Svetlov : -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Change by Mark Shannon : -- stage: resolved -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Change by Mark Shannon : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Ned Batchelder added the comment: Yes, this is fixed, thanks. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Mark Shannon added the comment: Ned, is this fixed for you now? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42760] inspect.iscoroutine returns False for asynchronous generator methods

Karthikeyan Singaravelan added the comment: This seems to be a duplicate of https://bugs.python.org/issue37190 -- nosy: +xtreak ___ Python tracker ___

[issue42760] inspect.iscoroutine returns False for asynchronous generator methods

Change by Kumar Aditya : -- nosy: +kumaraditya303 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Mark Shannon added the comment: Stefan, f_lineno can be None for some opcodes, but there shouldn't be trace events if it is. E.g. >>> def f(): ... try: ... 1/0 ... finally: ... pass ... >>> list(f.__code__.co_lines()) [(0, 2, 1), (2, 4, 2), (4, 12, 3), (12, 16,

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

end((map_trace_types(event, event), frame.f_lineno - frame.f_code.co_firstlineno)) TypeError: unsupported operand type(s) for -: 'NoneType' and 'int' https://github.com/cython/cython/blob/7ab11ec473a604792bae454305adece55cd8ab37/tests/run/line_trace.pyx No generator expressions involved, though. (

[issue46609] Generator-based coroutines in Python 3.10, 3.9 docs

Change by Terry J. Reedy : -- nosy: -miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed title: Generator-based coroutines in Python 3.10 docs -> Generator-based coroutines in Python 3.

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: New changeset 459e26f0987a12a19238baba422e13a8f7fcfca3 by Miss Islington (bot) in branch '3.9': [3.9] bpo-46609: Update asyncio-task coroutine doc (GH-31132) https://github.com/python/cpython/commit/459e26f0987a12a19238baba422e13a8f7fcfca3 --

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: New changeset 5603db43ba7ba5568b7516d0e28730a2bc1e1f26 by Terry Jan Reedy in branch '3.10': [3.10] bpo-46609: Update asyncio-task coroutine doc (GH-31132) https://github.com/python/cpython/commit/5603db43ba7ba5568b7516d0e28730a2bc1e1f26 --

[issue46609] Generator-based coroutines in Python 3.10 docs

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +29312 pull_request: https://github.com/python/cpython/pull/31133 ___ Python tracker

[issue46609] Generator-based coroutines in Python 3.10 docs

Change by Terry J. Reedy : -- keywords: +patch pull_requests: +29311 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31132 ___ Python tracker

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: Looking at the doc answered the question. Further down the 3.10 version, '3.10' was revised to '3.11', and indeed, the decorator and the entire section are gone. There was no change in 3.9 doc, but should be. I will submit a PR for 3.10 and try to

[issue46609] Generator-based coroutines in Python 3.10 docs

Terry J. Reedy added the comment: Yuri or Andrew: either of you know the fix for "Support for generator-based coroutines is deprecated and is scheduled for removal in Python 3.10."? -- nosy: +asvetlov, terry.reedy, yselivanov ___ Pyth

[issue46609] Generator-based coroutines in Python 3.10 docs

New submission from Sebastian Rittau : Currently, the Python 3.10.2 documentation at https://docs.python.org/3/library/asyncio-task.html?highlight=coroutine#asyncio.coroutine says: "Note: Support for generator-based coroutines is deprecated and is scheduled for removal in Python

[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 ___

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Change by Mark Shannon : -- assignee: -> Mark.Shannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

Mark Shannon added the comment: This has the same root cause as https://bugs.python.org/issue46374: closing the unused generator expression exposes the generator's frame before it has been initialized. -- ___ Python tracker <ht

[issue45686] ElementTree.Element.extend: bad error message when error occurs in generator

Change by Irit Katriel : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

New submission from Ned Batchelder : In Python 3.11, unused generator comprehensions cause trace events with f_lineno set to None. %< - import linecache, sys def trace(frame, event, arg): # The weird globals here is to av

[issue46009] sending non-None values makes generator raise StopIteration on next access

Christian Heimes added the comment: False alarm ... the frozen files for getpath.py were out of date. I can no longer reproduce the issue after a hard git clean and rebuild. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Christian Heimes : -- versions: +Python 3.11 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46009] sending non-None values makes generator raise StopIteration on next access

Christian Heimes added the comment: I got more debug symbols: python.js:235 Uncaught RuntimeError: null function or function signature mismatch at _PyEval_EvalFrameDefault (ceval.c:4247) at _PyEval_EvalFrame (pycore_ceval.h:48) at gen_send_ex2 (genobject.c:219) at

[issue46009] sending non-None values makes generator raise StopIteration on next access

Christian Heimes added the comment: GH-30367 broke Emscripten WASM builds. I'm getting a "null function or function signature mismatch" error from the WASM engine: RuntimeError: null function or function signature mismatch at _PyEval_EvalFrameDefault

[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 ___ ___

[issue46009] sending non-None values makes generator raise StopIteration on next access

Brandt Bucher added the comment: New changeset 31e43cbe5f01cdd5b5ab330ec3040920e8b61a91 by Brandt Bucher in branch 'main': bpo-46009: Remove GEN_START (GH-30367) https://github.com/python/cpython/commit/31e43cbe5f01cdd5b5ab330ec3040920e8b61a91 --

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Brandt Bucher : -- nosy: +brandtbucher nosy_count: 3.0 -> 4.0 pull_requests: +28580 pull_request: https://github.com/python/cpython/pull/30367 ___ Python tracker ___

[issue46175] Zero argument super() does not function properly inside generator expressions

Carlos Damazio added the comment: Josh: My mistake, I've seen a similar issue, then. And agreed, I think #2 is a great candidate since we don't need to re-design existing structures. I don't know a better option... yet. -- ___ Python tracker

[issue46175] Zero argument super() does not function properly inside generator expressions

. In comprehensions and generator expressions. Idea #2 could help in cases 3 and 4. -- ___ Python tracker <https://bugs.python.org/issue46175> ___ ___ Python-bugs-list m

[issue46175] Zero argument super() does not function properly inside generator expressions

Josh Rosenberg added the comment: Carlos: This has nothing to do with reloading (as Alex's repro shows, no reload calls are made). super() *should* behave the same as super(CLASS_DEFINED_IN, self), and it looks like the outer function is doing half of what it must do to make no-arg super()

[issue46175] Zero argument super() does not function properly inside generator expressions

Carlos Damazio added the comment: Normally, users assume it's safe to use `super` without explicit arguments, until an undefined behavior happens, such as now. The only thing that glances into this issue is the observation in the docs you've provided that omitting the second argument

[issue46175] Zero argument super() does not function properly inside generator expressions

TobiasHT added the comment: I'm not so sure, but I think this characteristic was carried from python 2. I guess it's not well documented because they assumed that people would carry on the knowledge to python 3. To be on the safe side, I always pass the arguments to super.

[issue46175] Zero argument super() does not function properly inside generator expressions

Carlos Damazio added the comment: By explicitly sending a type and object to the super function, it should work as usual, like in the file that I've just sent. I've seen this behavior before, it's related to Python's module reload function, which returns a new reference to the reloaded

[issue46175] Zero argument super() does not function properly inside generator expressions

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46175] Zero argument super() does not function properly inside generator expressions

New submission from Alex Walters : When zero argument super is used inside a generator expression, it raises 'TypeError: super(type, obj): obj must be an instance or subtype of type'. I can find no information on if this is working as intended, a bug, or a known issue, and the error isn't

[issue26951] [doc] Unintuitive error when using generator expression in class property

Change by Irit Katriel : -- title: Unintuitive error when using generator expression in class property -> [doc] Unintuitive error when using generator expression in class property versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.5, Python

[issue21964] inconsistency in list-generator comprehension with yield(-from)

Serhiy Storchaka added the comment: Resolved in issue10544. -- nosy: +serhiy.storchaka resolution: out of date -> duplicate stage: test needed -> resolved status: pending -> closed superseder: -> yield expression inside generator expression

[issue21964] inconsistency in list-generator comprehension with yield(-from)

= ((yield from i) for i in l) File "", line 1 SyntaxError: 'yield' inside generator expression -- nosy: +iritkatriel resolution: -> out of date status: open -> pending

[issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw()

Change by Irit Katriel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46009] sending non-None values makes generator raise StopIteration on next access

Pablo Galindo Salgado added the comment: New changeset 99c72326d245fb604609a87a51ef1ad0845467b7 by Mark Shannon in branch '3.10': [3.10] bpo-46009: Do not exhaust generator when send() method raises (GH-29986). (GH-29988) https://github.com/python/cpython/commit

[issue46009] sending non-None values makes generator raise StopIteration on next access

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

[issue46009] sending non-None values makes generator raise StopIteration on next access

Mark Shannon added the comment: New changeset 69806b9516dbe092381f3ef884c7c64bb9b8414a by Mark Shannon in branch 'main': bpo-46009: Do not exhaust generator when send() method raises (GH-29986) https://github.com/python/cpython/commit/69806b9516dbe092381f3ef884c7c64bb9b8414a

[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

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Mark Shannon : -- keywords: +patch pull_requests: +28209 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29986 ___ 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

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Pablo Galindo Salgado : -- nosy: +pablogsal priority: normal -> release blocker ___ Python tracker ___ ___

[issue46009] sending non-None values makes generator raise StopIteration on next access

Change by Pablo Galindo Salgado : -- nosy: +Mark.Shannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[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 ___ ___

[issue45963] Embed interpreter frame in generator.

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45963] Embed interpreter frame in generator.

Change by Pablo Galindo Salgado : -- priority: release blocker -> ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46009] sending non-None values makes generator raise StopIteration on next access

) except TypeError as e: print(e) # can't send non-None value to a just-started generator print(next(x)) -- messages: 407975 nosy: Zabolekar priority: normal severity: normal status: open title: sending non-None values makes generator raise StopIteration on next access type

[issue45963] Embed interpreter frame in generator.

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

[issue45963] Embed interpreter frame in generator.

Mark Shannon added the comment: I'll look into it now, and fix or revert it. -- ___ Python tracker ___ ___ Python-bugs-list

[issue45963] Embed interpreter frame in generator.

Pablo Galindo Salgado added the comment: This is also unfortunately blocking the 3.11.a3 release :( -- priority: normal -> release blocker ___ Python tracker ___

[issue45963] Embed interpreter frame in generator.

Author: Mark Shannon Date: Mon Dec 6 10:13:49 2021 + bpo-45963: Make space for the InterpreterFrame of a generator in that generator. (GH-29891) * Make generator, coroutine and async gen structs all the same size. * Store interpreter frame in generator (and coroutine

[issue41174] asyncio.coroutine decorator returns a non-generator function when using PYTHONASYNCIODEBUG

Change by Irit Katriel : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41174] asyncio.coroutine decorator returns a non-generator function when using PYTHONASYNCIODEBUG

Andrew Svetlov added the comment: Agree, thanks! -- status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41174] asyncio.coroutine decorator returns a non-generator function when using PYTHONASYNCIODEBUG

Irit Katriel added the comment: asyncio.coroutine was removed in 3.11, and I don't think this will be changed in stable versions. I will close this issue unless I am corrected. -- nosy: +iritkatriel resolution: -> wont fix status: open -> pending

[issue45963] Embed interpreter frame in generator.

Mark Shannon added the comment: New changeset 299483c95d601ddcfdce2f96418b6499c1fc7b9f by Mark Shannon in branch 'main': bpo-45963: Make space for the InterpreterFrame of a generator in that generator. (GH-29891) https://github.com/python/cpython/commit

[issue45963] Embed interpreter frame in generator.

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

[issue45963] Embed interpreter frame in generator.

New submission from Mark Shannon : Currently, the InterpreterFrame for a generator is allocated on the heap separately from the generator. This means that 2 allocations are needed to create a generator, and an extra indirection is needed to get from the generator to the frame. By embedding

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

miss-islington added the comment: New changeset a427eb862f11888fa69fee520eb8a20bd396fcdb by Miss Islington (bot) in branch '3.10': bpo-45494: Fix error location in EOF tokenizer errors (GH-29108) https://github.com/python/cpython/commit/a427eb862f11888fa69fee520eb8a20bd396fcdb --

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +27911 pull_request: https://github.com/python/cpython/pull/29672 ___ Python tracker

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Pablo Galindo Salgado added the comment: New changeset 79ff0d1687e3f823fb121a19f0297ad052871b1b by Pablo Galindo Salgado in branch 'main': bpo-45494: Fix error location in EOF tokenizer errors (GH-29108) https://github.com/python/cpython/commit/79ff0d1687e3f823fb121a19f0297ad052871b1b

[issue45686] ElementTree.Element.extend: bad error message when error occurs in generator

New submission from Michael Wayne Goodman : Both the Python and C versions of xml.etree.ElementTree allow Element.extend() to accept a sequence or an iterable, such as a generator expression (although the docs only mention "sequence"; that's a separate problem): >>> fr

[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.

: print("caught") print(g.send(None)) print(g.send(100)) print(g.send(200)) This used to work prior to commit b37181e69209746adc2119c471599a1ea5faa6c8. But after that commit it fails on the print(g.send(None)) because the generator is now stopped. -- nosy:

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Change by Pablo Galindo Salgado : -- pull_requests: +27376 pull_request: https://github.com/python/cpython/pull/29108 ___ Python tracker ___

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Łukasz Langa added the comment: Thanks for the fix, Pablo! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Łukasz Langa added the comment: New changeset 88f4ec88e282bf861f0af2d237e9fe28fbc8deac by Łukasz Langa in branch '3.9': [3.9] bpo-45494: Fix parser crash when reporting errors involving invalid continuation characters (GH-28993) (#29071)

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Łukasz Langa added the comment: Note: this *does* fail on 3.9, too. Even if it doesn't crash the production build, it does fail an assertion in a pydebug build: test_error_offset_continuation_characters (test.test_exceptions.ExceptionTests) ... Assertion failed: (!_PyErr_Occurred(tstate)),

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Łukasz Langa added the comment: New changeset 5c9cab595e56aeb118bff77ece784dbac30b4338 by Łukasz Langa in branch '3.10': [3.10] bpo-45494: Fix parser crash when reporting errors involving invalid continuation characters (GH-28993) (GH-29070)

[issue45494] [fuzzer] Parser null deref with continuation characters and generator parenthesis error

Change by Łukasz Langa : -- pull_requests: +27339 pull_request: https://github.com/python/cpython/pull/29071 ___ Python tracker ___

  1   2   3   4   5   6   7   8   9   10   >