Overall, the whole change looks like the right approach. I will wait until the PR is not marked as draft to review it in depth.

Thanks! As far as I'm aware there are only 2 things that currently hold me from marking this PR as ready to review, one is some silly typing failures (will look them) and the other one is issue 40794.

I think this is in part on me -- I started a review but never finished it. IIRC there were also some unresolved problems, but I don't know if they are still unresolved.

I'm giving a rebase right now, and try to merge the latest typing changes on get_type_hints etc with current version. Please do not review until I push the latest changes (at worst tomorrow)

Found a different example for double-stringified sources in dataclasses (this used to work, but now it can't get parsed by the static regex in the dataclasses module since now there are extra quotes);

import typing
from dataclasses import dataclass

@dataclass
class T:
    a: "typing.ClassVar[int]"

T()

We can either handle it like how we do in the ForwardRef, or solve these all problems completely in the compiler level by doing something like this;

+++ b/Python/compile.c
@@ -2016,7 +2016,15 @@ error:
 static int
 compiler_visit_annexpr(struct compiler *c, expr_ty annotation)
 {
-    ADDOP_LOAD_CONST_NEW(c, _PyAST_ExprAsUnicode(annotation));
+    PyObject *value;
+    if (annotation->kind == Constant_kind && PyUnicode_CheckExact(annotation->v.Constant.value)) {
+        value = annotation->v.Constant.value;
+        Py_INCREF(value);
+    }
+    else {
+        value = _PyAST_ExprAsUnicode(annotation);
+    }
+    ADDOP_LOAD_CONST_NEW(c, value);
     return 1;
 }

Any suggestions @gvanrossum?

I don't think that solves it completely, does it? ISTM we still get double quotes when the annotation contains a string literal as a generic parameter (e.g., list["int"]). And it doesn't produce the same result with the future import in 3.9. It also seems quite inconsistent to say "annotations get stringified except if they are already strings" -- this makes it impossible to reconstruct the original annotation by un-stringifying.

I'd rather fix this in dataclasses.py and backport the fix to 3.9.1 (since it's clearly too late for 3.9.0 :-).

As a side effect, this now folds into Optional[int]

@dataclass
class C:
    x: Union[int, type(None)] = None

- C.__doc__ == C(x:'Union[int, type(None)]'=None)
+ C.__doc__ == C(x:Optional[int]=None)

As a side effect, this now folds into Optional[int]

@dataclass
class C:
    x: Union[int, type(None)] = None

- C.__doc__ == C(x:'Union[int, type(None)]'=None)
+ C.__doc__ == C(x:Optional[int]=None)

But note that type(None) is invalid according to PEP 484 -- it should just be None.

But note that type(None) is invalid according to PEP 484 -- it should just be None.

I just copied over the test case, my point was we are changing the shape of a declaration;

>>> from typing import *
>>> def x(a: Union[int, None]): pass
... 
>>> inspect.signature(x)
<Signature (a: Optional[int])>

But it is not much of a big deal, I guess, just wanted to mention about it

But note that type(None) is invalid according to PEP 484 -- it should just be None.

I just copied over the test case, my point was we are changing the shape of a declaration;

>>> from typing import *
>>> def x(a: Union[int, None]): pass
... 
>>> inspect.signature(x)
<Signature (a: Optional[int])>

But it is not much of a big deal, I guess, just wanted to mention about it

Hm, your comment was not linked to any particular line of code.

FWIW that behavior is built into typing.Union:

>>> import typing
>>> typing.Union[int, None]
typing.Optional[int]
>>> 

I betcha you didn't expect it to be this subtle. (I know I didn't.)

Indeed!

Well done @isidentical!