You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers #80461
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/gvanrossum'closed_at=<Date2019-03-13.20:01:54.579>created_at=<Date2019-03-13.04:00:08.733>labels= ['type-bug', '3.8']
title='Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers'updated_at=<Date2019-03-13.20:01:54.578>user='https://github.com/gvanrossum'
On second thought, even though it's a subclass, it feels less consistent than an extra attribute. So I'd rather keep the current approach (kind -> 'u' or None).
Please correct me if I'm wrong. This Constant.kind field is not used in mypy any more. Previously it was used in fastparse.py (intro by this commit: python/mypy@69a5a02), but now I don't see it in mypy/fastparse.py or anywhere else. Yes, this field is present in ast module interface, and I didn't try to search if it is used by some PyPI package. Maybe you know where it is used. Thanks!
@gvanrossum Initially I wanted to remove this field as it looked outdated. I've even prepared draft commit vasily-v-ryabov@68906e0 but then I've found this thread and related commits, and also I understood it may potentially break backward compatibility. If there is no such risk, I'd suggest to create a PR or prepare some deprecation. Though this particular commit is not critical to me if this stuff is really used.
The reason to me is making AST more compact which should be generally good for performance. I'm interested in improvements for AST and compiler related stuff in CPython for my project (hope it will be open in the future).
Activity
serhiy-storchaka commentedon Mar 13, 2019
Maybe use a special subclass of Constant for indicating string literals with the "u" prefix?
gvanrossum commentedon Mar 13, 2019
That would indeed be more convenient, as it requires fewer code and test changes. Are there examples of such classes in Python.asdl?
gvanrossum commentedon Mar 13, 2019
On second thought, even though it's a subclass, it feels less consistent than an extra attribute. So I'd rather keep the current approach (kind -> 'u' or None).
miss-islington commentedon Mar 13, 2019
New changeset 10f8ce6 by Miss Islington (bot) (Guido van Rossum) in branch 'master':
bpo-36280: Add Constant.kind field (GH-12295)
10f8ce6
gvanrossum commentedon Mar 13, 2019
Thanks for the review Serhiy!
vasily-v-ryabov commentedon Nov 1, 2023
Please correct me if I'm wrong. This
Constant.kindfield is not used in mypy any more. Previously it was used infastparse.py(intro by this commit: python/mypy@69a5a02), but now I don't see it in mypy/fastparse.py or anywhere else. Yes, this field is present inastmodule interface, and I didn't try to search if it is used by some PyPI package. Maybe you know where it is used. Thanks!gvanrossum commentedon Nov 1, 2023
@vasily-v-ryabov What is your question, or what action are you requesting we take?
vasily-v-ryabov commentedon Nov 2, 2023
@gvanrossum Initially I wanted to remove this field as it looked outdated. I've even prepared draft commit vasily-v-ryabov@68906e0 but then I've found this thread and related commits, and also I understood it may potentially break backward compatibility. If there is no such risk, I'd suggest to create a PR or prepare some deprecation. Though this particular commit is not critical to me if this stuff is really used.
The reason to me is making AST more compact which should be generally good for performance. I'm interested in improvements for AST and compiler related stuff in CPython for my project (hope it will be open in the future).