The Wayback Machine - https://web.archive.org/web/20250627113118/https://github.com/python/cpython/pull/27330
Skip to content

bpo-36643: Unwrap ForwardRefs and string types in dataclasses.fields() result #27330

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

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

bpo-36643: Unwrap ForwardRefs and string types in dataclasses.fields() result #27330

wants to merge 2 commits into from

Conversation

mdrachuk
Copy link

@mdrachuk mdrachuk commented Jul 24, 2021 •
edited by bedevere-bot
Loading

dataclasses.fields() returns dataclasses.Field instances which can have Field.type to be actual types, ForwardRef or str (in case of __future__.annotations). This behaviour is overall obscure leaking implementation details, and making every user of fields() reimplement the unwrapping of types, mixing between dataclasses.fields() and typing.get_type_hints() (which does perform unwrapping of types).

This PR fixes this behaviour by unwrapping the types during fields() execution.

Also, see https://bugs.python.org/issue36643

Please let me know if there are any documentation, code style, or implementation changes that need to be performed for this to be merged.

(On a side note: it seems like Field is marked as an internal object in documentation — it is said not to be instantiated directly by users. Call to fields() returns Field objects, but it seems like no builtins use anything except for Field.name when calling fields(). Maybe it is better to separate internal/external APIs here in some way?)

https://bugs.python.org/issue36643

@mdrachuk mdrachuk requested a review from ericvsmith as a code owner July 24, 2021 11:12
@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@mdrachuk

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Aug 24, 2021
@JelleZijlstra
Copy link
Member

Added "do not merge" per Eric's comments on the bug.

@iritkatriel
Copy link
Member

https://bugs.python.org/issue36643 is closed. What is the status of this PR?

@JelleZijlstra
Copy link
Member

Thanks, but we'd prefer to keep dataclasses.fields simple and not execute typing-specific transformations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ericvsmith ericvsmith Awaiting requested review from ericvsmith ericvsmith is a code owner

Assignees
No one assigned
Labels
awaiting review DO-NOT-MERGE stale Stale PR or inactive for long period of time.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@mdrachuk @the-knights-who-say-ni @JelleZijlstra @iritkatriel @bedevere-bot