Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-96151: Use a private name for passing builtins to dataclass #98143

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.

Sign up for GitHub

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

Merged
ericvsmith merged 8 commits into from
Oct 31, 2022
Merged

gh-96151: Use a private name for passing builtins to dataclass #98143

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3e03d52
gh-96151: Use a private name for passing builtins to dataclass
hauntsaninja Oct 10, 2022
7f9f91e
📜🤖 Added by blurb_it.
blurb-it[bot] Oct 10, 2022
2d5f290
add a test case
hauntsaninja Oct 11, 2022
d7e8782
separate out test
hauntsaninja Oct 11, 2022
96cc82b
use dunder builtins
hauntsaninja Oct 17, 2022
e7456f8
actually, prefix with __dataclass
hauntsaninja Oct 30, 2022
8f6e968
Remove builtins logic from _create_fn
hauntsaninja Oct 31, 2022
9d44429
also update comment
hauntsaninja Oct 31, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions Lib/dataclasses.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -431,8 +431,8 @@ def _create_fn(name, args, body, *, globals=None, locals=None,
# worries about external callers.
if locals is None:
locals = {}
if 'BUILTINS' not in locals:
Copy link
Copy Markdown
Member

@JelleZijlstra JelleZijlstra Oct 15, 2022

Choose a reason for hiding this comment

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

I'd suggest using __BUILTINS__ because dunder names are supposed to be reserved for use by the stdlib.

Copy link
Copy Markdown
Member

@ericvsmith ericvsmith Oct 30, 2022

Choose a reason for hiding this comment

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

Before I commit this, I'd like to spend some time researching why this test is even present, instead of just unconditionally assigning to locals. At the very least it could use a comment.

Also, I'm not sure that exposing all of builtins in locals is a good idea, versus just exposing builtins.object.

Copy link
Copy Markdown
Contributor Author

@hauntsaninja hauntsaninja Oct 30, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

Good catch, looks like the relevant history is:

That is, I think this check was made dead in #9518, but wasn't noticed in that PR

(Also note that the comment at the top of _create_fn is out of date: we do mutate locals, but not via exec)

Copy link
Copy Markdown
Contributor Author

@hauntsaninja hauntsaninja Oct 30, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

I can do some double checking (locals should all be created within dataclasses.py) and clean that up + change the PR to only pass along object.

(I'll also note that there's still the inscrutable ().__class__.__base__ option on the table, in case we don't want to expose anything at all)

Copy link
Copy Markdown
Contributor Author

@hauntsaninja hauntsaninja Oct 31, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

Okay, I audited all the call sites, it looks like there is one case where this check is not dead, but it's accidental.

Over here we reuse the same locals dict for two different _create_fn calls:

cpython/Lib/dataclasses.py

Line 619 in 87b5fd9

locals = {'cls': cls,

so the second time round we already have the entry for builtins in the dict. shrug

So my conclusion is:
a) It's safe to remove the check.
b) We should actually go a little further. Since we only need builtins for the frozen init, we should pass that in explicitly when creating __init__ and remove this from _create_fn

I've gone ahead and pushed this change to the PR

locals['BUILTINS'] = builtins
if '_BUILTINS' not in locals:
locals['_BUILTINS'] = builtins
return_annotation = ''
if return_type is not MISSING:
locals['_return_type'] = return_type
Expand Down Expand Up @@ -462,7 +462,7 @@ def _field_assign(frozen, name, value, self_name):
# self_name is what "self" is called in this function: don't
# hard-code "self", since that might be a field name.
if frozen:
return f'BUILTINS.object.__setattr__({self_name},{name!r},{value})'
return f'_BUILTINS.object.__setattr__({self_name},{name!r},{value})'
return f'{self_name}.{name}={value}'


Expand Down
1 change: 1 addition & 0 deletions Misc/NEWS.d/next/Library/2022-10-10-07-07-31.gh-issue-96151.K9fwoq.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Allow ``BUILTINS`` to be a valid field name for frozen dataclasses.