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

Fix strict optional handling in dataclasses #15571

Merged
merged 3 commits into from
Jul 3, 2023

Conversation

ilevkivskyi
Copy link
Member

There were few cases when someone forgot to call strict_optional_set() in dataclasses plugin, let's move the calls directly to two places where they are needed for typeops. This may cause a tiny perf regression, but is much more robust in terms of preventing bugs.

@github-actions

This comment has been minimized.

Copy link
Collaborator

@cdce8p cdce8p left a comment

Choose a reason for hiding this comment

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

Thanks @ilevkivskyi!

I do wonder though if we should completely remove the --strict-optional flag rather sooner than later. It's the default already and this type of issue here seems to come up often. Also a small performance improvement as state.strict_optional_set wouldn't be needed.

@@ -2420,3 +2420,16 @@ class Test(Protocol):
def reset(self) -> None:
self.x = DEFAULT
[builtins fixtures/dataclasses.pyi]

[case testStrictOptionalAlwaysSet]
# flags: --strict-optional
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
# flags: --strict-optional

--strict-optional is the default. So the flag wouldn't be necessary.

Copy link
Member Author

Choose a reason for hiding this comment

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

--strict-optional is actually off by default in tests (at least for testcheck.py).

Copy link
Member Author

Choose a reason for hiding this comment

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

But this actually reminded me that this test should use real stubs, so it should be moved to pythoneval.test.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Interesting, before writing the initial comment, I removed the flag from the test case and it still passed 🤔

--strict-optional is actually off by default in tests (at least for testcheck.py).

I enabled it for pythoneval tests in #15474, seems I should work on the rest as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Interesting, before writing the initial comment, I removed the flag from the test case and it still passed

This is exactly why I moved it to pythoneval, otherwise it doesn't really test much.

@ilevkivskyi
Copy link
Member Author

I do wonder though if we should completely remove the --strict-optional flag rather sooner than later

This is an important flag. We can remove it at some point, but I don't think we are there yet. I bet multiple large mypy users still use it (likely on per-file basis), at least this is what I can say from recent personal experience.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

github-actions bot commented Jul 3, 2023

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@ilevkivskyi ilevkivskyi merged commit 5e4d097 into python:master Jul 3, 2023
@ilevkivskyi ilevkivskyi deleted the fix-dataclass-optional branch July 3, 2023 19:20
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