Repository navigation
Statically Initialize PyArg_Parser in clinic.py #90928
Description
| BPO | 46772 |
|---|---|
| Nosy | @ericsnowcurrently |
| Dependencies |
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 = 'https://github.com/ericsnowcurrently'
closed_at = None
created_at = <Date 2022-02-16.18:32:25.886>
labels = ['interpreter-core', '3.11']
title = 'Statically Initialize PyArg_Parser in clinic.py'
updated_at = <Date 2022-02-16.18:36:54.761>
user = 'https://github.com/ericsnowcurrently'bugs.python.org fields:
activity = <Date 2022-02-16.18:36:54.761>
actor = 'eric.snow'
assignee = 'eric.snow'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2022-02-16.18:32:25.886>
creator = 'eric.snow'
dependencies = ['46753', '46773']
files = []
hgrepos = []
issue_num = 46772
keywords = []
message_count = 1.0
messages = ['413351']
nosy_count = 1.0
nosy_names = ['eric.snow']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue46772'
versions = ['Python 3.11']
Activity
ericsnowcurrently commentedon Feb 16, 2022
The code generated by clinic.py is already partially statically initialized. Currently we init the other fields in Python/getargs.c:parser_init(), which runs the first time we try to use each parser. AFAICS, that remaining init that could be done statically using the data we have available in clinic.py during code generation.
My primary interest is in static init of PyArg_Parser.kwtuple, which is a tuple containing only strings.
gh-90928: Statically Initialize the Keywords Tuple in Clinic-Generate…
ericsnowcurrently commentedon Aug 12, 2022
gh-95909 follows up on interpreter isolation for
PyArg_Parser.gh-90928: Improve static initialization of keywords tuple in AC (#95907)