delta/cpython-git.git/Parser, branch main github.com: python/cpython.git gh-103763: Implement PEP 695 (#103764) 2023-05-16T03:36:23+00:00 Jelle Zijlstra jelle.zijlstra@gmail.com 2023-05-16T03:36:23+00:00 24d8b88420b81fc60aeb0cbcacef1e72d633824a This implements PEP 695, Type Parameter Syntax. It adds support for: - Generic functions (def func[T](): ...) - Generic classes (class X[T](): ...) - Type aliases (type X = ...) - New scoping when the new syntax is used within a class body - Compiler and interpreter changes to support the new syntax and scoping rules Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com> Co-authored-by: Eric Traut <eric@traut.com> Co-authored-by: Larry Hastings <larry@hastings.org> Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com> 
This implements PEP 695, Type Parameter Syntax. It adds support for:

- Generic functions (def func[T](): ...)
- Generic classes (class X[T](): ...)
- Type aliases (type X = ...)
- New scoping when the new syntax is used within a class body
- Compiler and interpreter changes to support the new syntax and scoping rules 

Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
Co-authored-by: Eric Traut <eric@traut.com>
Co-authored-by: Larry Hastings <larry@hastings.org>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
 Trim trailing whitespace and test on CI (#104275) 2023-05-08T14:03:52+00:00 Hugo van Kemenade hugovk@users.noreply.github.com 2023-05-08T14:03:52+00:00 d513ddee94a05783b98f2b55f8fc0a4efbb9be82 Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com> 
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
gh-99113: Add Py_MOD_PER_INTERPRETER_GIL_SUPPORTED (gh-104205) 2023-05-05T21:11:27+00:00 Eric Snow ericsnowcurrently@gmail.com 2023-05-05T21:11:27+00:00 a9c6e0618f26270e2591b3d99ffeef55eea02a33 Here we are doing no more than adding the value for Py_mod_multiple_interpreters and using it for stdlib modules. We will start checking for it in gh-104206 (once PyInterpreterState.ceval.own_gil is added in gh-104204). 
Here we are doing no more than adding the value for Py_mod_multiple_interpreters and using it for stdlib modules.  We will start checking for it in gh-104206 (once PyInterpreterState.ceval.own_gil is added in gh-104204).
 gh-104169: Ensure the tokenizer doesn't overwrite previous errors (#104170) 2023-05-04T14:15:26+00:00 Pablo Galindo Salgado Pablogsal@gmail.com 2023-05-04T14:15:26+00:00 eba64d2afb4c429e80d863dc0dd7808bdbef30d3 






gh-97556: Raise null bytes syntax error upon null in multiline string (GH-104136)
2023-05-04T12:26:23+00:00

Lysandros Nikolaou
lisandrosnik@gmail.com

2023-05-04T12:26:23+00:00

ef0df5284f929719b2ef3955b1b569ade0a5193c












gh-104016: Fixed off by 1 error in f string tokenizer (#104047)
2023-05-01T19:15:47+00:00

jx124
64946984+jx124@users.noreply.github.com

2023-05-01T19:15:47+00:00

5078eedc5b18f0d208af6e30f60b33419132d1b6

Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
Co-authored-by: Ken Jin <kenjin@python.org>
Co-authored-by: Pablo Galindo <pablogsal@gmail.com>





Co-authored-by: sunmy2019 <59365878+sunmy2019@users.noreply.github.com>
Co-authored-by: Ken Jin <kenjin@python.org>
Co-authored-by: Pablo Galindo <pablogsal@gmail.com>







gh-103824: fix use-after-free error in Parser/tokenizer.c (#103993)
2023-05-01T15:26:43+00:00

chgnrdv
52372310+chgnrdv@users.noreply.github.com

2023-05-01T15:26:43+00:00

d5a97074d24cd14cb2a35a2b1ad3074863cde264












gh-103656: Transfer f-string buffers to parser to avoid use-after-free (GH-103896)
2023-04-27T01:33:31+00:00

Lysandros Nikolaou
lisandrosnik@gmail.com

2023-04-27T01:33:31+00:00

9169a56fad246364fd3224306e72e0d0725c35aa

Co-authored-by: Pablo Galindo <pablogsal@gmail.com>




Co-authored-by: Pablo Galindo <pablogsal@gmail.com>






gh-103718: Correctly set f-string buffers in all cases (GH-103815)
2023-04-25T01:31:21+00:00

Lysandros Nikolaou
lisandrosnik@gmail.com

2023-04-25T01:31:21+00:00

57f8f9a66d4d0b5e590f7746a58136b3b45b1336

Turns out we always need to remember/restore fstring buffers in all of
the stack of tokenizer modes, cause they might change to
`TOK_REGULAR_MODE` and have newlines inside the braces (which is when we
need to reallocate the buffer and restore the fstring ones).




Turns out we always need to remember/restore fstring buffers in all of
the stack of tokenizer modes, cause they might change to
`TOK_REGULAR_MODE` and have newlines inside the braces (which is when we
need to reallocate the buffer and restore the fstring ones).






GH-103727: Avoid advancing tokenizer too far in f-string mode (GH-103775)
2023-04-24T18:30:21+00:00

Lysandros Nikolaou
lisandrosnik@gmail.com

2023-04-24T18:30:21+00:00

cb157a1a353675cb6f08bdae5d7aadd6b28bb0a9