Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add basic support for PEP 695 #5842

Closed
wants to merge 5 commits into from
Closed

Add basic support for PEP 695 #5842

wants to merge 5 commits into from

Conversation

zanieb
Copy link
Member

@zanieb zanieb commented Jul 17, 2023

Part of #5062

Summary

Adds basic boilerplate support for PEP 695 without the expectation that we will actually do anything with the contents of such expressions.

Bumps our RustPython/Parser fork to get support for PEP 695 as tracked by RustPython/Parser#82

Test Plan

self.unparse_expr(name, precedence::MAX);
for type_param in type_params {
self.unparse_type_param(type_param);
self.p(", ")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to get a little more sophisticated in handling trailing comma, I presume.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check out the self.p_delim(&mut first, ", "); line in the Stmt::With case.

bound.as_ref().map_or(false, |value| any_over_expr(value, func))
}
TypeParam::TypeVarTuple(ast::TypeParamTypeVarTuple { .. }) => {
false
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should any_over_expr visit names?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should visit all expressions, so needs to recurse on anything that might contain an expression.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The names can't contain expressions, they're just containers for a string. It seems like a pain if you were trying to visit parameter names here but I guess we can tackle that with another helper (or as it comes up).

@github-actions
Copy link
Contributor

PR Check Results

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.01      9.4±0.06ms     4.3 MB/sec    1.00      9.3±0.02ms     4.4 MB/sec
formatter/numpy/ctypeslib.py               1.00   1856.7±3.01µs     9.0 MB/sec    1.00   1850.6±3.45µs     9.0 MB/sec
formatter/numpy/globals.py                 1.00    205.0±0.44µs    14.4 MB/sec    1.01    206.7±0.51µs    14.3 MB/sec
formatter/pydantic/types.py                1.02      4.1±0.01ms     6.3 MB/sec    1.00      4.0±0.01ms     6.4 MB/sec
linter/all-rules/large/dataset.py          1.00     13.3±0.07ms     3.1 MB/sec    1.02     13.6±0.25ms     3.0 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.01      3.3±0.01ms     5.0 MB/sec    1.00      3.3±0.01ms     5.0 MB/sec
linter/all-rules/numpy/globals.py          1.00    440.4±1.37µs     6.7 MB/sec    1.00    440.4±0.48µs     6.7 MB/sec
linter/all-rules/pydantic/types.py         1.00      5.9±0.01ms     4.3 MB/sec    1.00      5.9±0.03ms     4.3 MB/sec
linter/default-rules/large/dataset.py      1.00      6.5±0.02ms     6.2 MB/sec    1.00      6.5±0.02ms     6.2 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.01   1418.4±6.07µs    11.7 MB/sec    1.00   1409.0±1.33µs    11.8 MB/sec
linter/default-rules/numpy/globals.py      1.01    157.9±0.93µs    18.7 MB/sec    1.00    155.6±0.24µs    19.0 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.0±0.01ms     8.6 MB/sec    1.00      2.9±0.01ms     8.7 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
formatter/large/dataset.py                 1.01     11.3±0.13ms     3.6 MB/sec    1.00     11.2±0.12ms     3.6 MB/sec
formatter/numpy/ctypeslib.py               1.02      2.2±0.04ms     7.7 MB/sec    1.00      2.1±0.03ms     7.8 MB/sec
formatter/numpy/globals.py                 1.00    230.8±4.07µs    12.8 MB/sec    1.01    232.5±5.39µs    12.7 MB/sec
formatter/pydantic/types.py                1.00      4.8±0.08ms     5.3 MB/sec    1.00      4.8±0.08ms     5.3 MB/sec
linter/all-rules/large/dataset.py          1.00     15.7±0.19ms     2.6 MB/sec    1.00     15.8±0.18ms     2.6 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.2±0.05ms     4.0 MB/sec    1.00      4.1±0.10ms     4.0 MB/sec
linter/all-rules/numpy/globals.py          1.00    422.7±8.37µs     7.0 MB/sec    1.01   425.3±10.23µs     6.9 MB/sec
linter/all-rules/pydantic/types.py         1.00      7.2±0.14ms     3.6 MB/sec    1.00      7.1±0.05ms     3.6 MB/sec
linter/default-rules/large/dataset.py      1.00      8.1±0.14ms     5.0 MB/sec    1.00      8.1±0.06ms     5.0 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.01  1647.6±25.82µs    10.1 MB/sec    1.00  1625.3±31.98µs    10.2 MB/sec
linter/default-rules/numpy/globals.py      1.01    172.8±3.88µs    17.1 MB/sec    1.00    170.8±2.01µs    17.3 MB/sec
linter/default-rules/pydantic/types.py     1.02      3.7±0.10ms     7.0 MB/sec    1.00      3.6±0.02ms     7.1 MB/sec

@zanieb
Copy link
Member Author

zanieb commented Jul 18, 2023

Superseded by #5459

@zanieb zanieb closed this Jul 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants