A note about commit messages / PR titles:something does something is ambiguous because it could be describing wrong behaviour that the code did before the change, or new correct behaviour. Similar to the docstring convention (method columnize:Display a list of blah by blah), a good commit message or PR title should show what thechanges do:

• Fix extra space added by columnize (better than: columnize adds extra space (a bug))
• Add extra space in columnize (better than: columnize adds extra space (a feature))
• columnize now adds extra space when needed (same — present tense +now avoids ambiguity)

So for this PR (if I understand current title correctly) it could be:

• Do not add Optional in get_type_hints
• Make get_type_hints not add Optional

@merwok thanks, it is way more readable now! Wording (and writing in general) in English is something I really try to improve.

@Zac-HD do we rely on this behavior inhypothesis? 🤔

@Zac-HD do we rely on this behavior inhypothesis? 🤔

It's certainly observable by our users, and would probably make some of our tests fail.

That said, I support the more consistent design proposed in the BPO issue, and we'll be fine carrying another clause in our type hints wrapper in Hypothesis. Probably important to reference the relevant PEP (section of 484, I think?) in the changelog though.

Will this be applied in Python 3.11, or is it intended to be back-ported to previous versions?

In my opinion this should be 3.11+ only 🤔
But, there might be other opinions of course.

I have production code that currently assumes parameters that default toNone are implicitlyOptional; the required changes to accommodate this are trivial on my part, and I can certainly plan within the 3.11 time horizon.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

In my opinion this should be 3.11+ only 🤔

Yeah. This is definitely a breaking change so it should be 3.11+ only. I wonder how many runtime checkers are affected or even useget_type_hints for that matter?@samuelcolvin can I trouble you for an opinion on this please?@Tinche too for cattrs too please. Thank you.

In short,typing.get_type_hints automatically wraps a type annotation withOptional if it sees a defaultNone. This PR proposes to cease that behavior.

@Fidget-Spinner I'm totally fine with this, correct change in my opinion.

Just out of curiosity, does this change only apply to function parameters or class members too?

@Tinche for classesOptional was never added implictly (which is another point why we should fix this inconsistency).

Here are two examples,main and3.9:

» ./python.exePython3.11.0a3+ (heads/main:e13cdca0f5,Jan112022,12:43:49) [Clang11.0.0 (clang-1100.0.33.16)]ondarwinType"help","copyright","credits"or"license"formoreinformation.>>>importtyping>>>classA:...x:int=None...>>>typing.get_type_hints(A){'x':<class'int'>}

»pythonPython3.9.9 (main,Dec212021,11:35:28) [Clang11.0.0 (clang-1100.0.33.16)]ondarwinType"help","copyright","credits"or"license"formoreinformation.>>>importtyping>>>classA:...x:int=None...>>>typing.get_type_hints(A){'x':<class'int'>}

However, I can't find a test case for this 🤔

@Tinche for classesOptional was never added implictly (which is another point why we should fix this inconsistency).

Here are two examples,main and3.9:

» ./python.exePython3.11.0a3+ (heads/main:e13cdca0f5,Jan112022,12:43:49) [Clang11.0.0 (clang-1100.0.33.16)]ondarwinType"help","copyright","credits"or"license"formoreinformation.>>>importtyping>>>classA:...x:int=None...>>>typing.get_type_hints(A){'x':<class'int'>}

»pythonPython3.9.9 (main,Dec212021,11:35:28) [Clang11.0.0 (clang-1100.0.33.16)]ondarwinType"help","copyright","credits"or"license"formoreinformation.>>>importtyping>>>classA:...x:int=None...>>>typing.get_type_hints(A){'x':<class'int'>}

However, I can't find a test case for this 🤔

Thanks for the info!

Thanks for the great question! 👍

I've added this corner case to our tests in a separate PR:#30535

In my opinion this should be 3.11+ only thinking

Yeah. This is definitely a breaking change so it should be 3.11+ only. I wonder how many runtime checkers are affected or even useget_type_hints for that matter?@samuelcolvin can I trouble you for an opinion on this please?@Tinche too for cattrs too please. Thank you.

In short,typing.get_type_hints automatically wraps a type annotation withOptional if it sees a defaultNone. This PR proposes to cease that behavior.

Thanks@Fidget-Spinner for asking my opinion, really useful to get a heads up about things like this. I don'tthink it will affect pydantic, if it does we can take care of it when adding support for 3.11.

I'm happy with this change provided it's no back-ported to other versions of python.

Just re-found this issue because Hypothesis does indeed have a test for this 😂

Let's mention this change inhttps://docs.python.org/3.11/whatsnew/3.11.html, not just the docs fortyping.get_type_hints().