This works:

    𝕕𝕖𝕗 = 1

This raises SyntaxError:

    import ast
    exec(ast.unparse(ast.parse("𝕕𝕖𝕗 = 1")))

It looks like `ast.parse` creates a `Name` node with `id='def'`, which is correct per PEP 3131, but `ast.unparse` doesn't know it needs to mangle the output somehow, as "𝕕𝕖𝕗" or a similar Unicode replacement.

I can confirm that it happens on all versions from 3.9 to 3.11 (main).

```
Python 3.9.9 (main, Dec 21 2021, 11:35:28) 
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.unparse(ast.parse("𝕕𝕖𝕗 = 1"))
'def = 1'
>>> exec(ast.unparse(ast.parse("𝕕𝕖𝕗 = 1")))  # SyntaxError
```

```
Python 3.11.0a4+ (heads/main-dirty:ef3ef6fa43, Jan 20 2022, 20:48:25) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.unparse(ast.parse("𝕕𝕖𝕗 = 1"))
'def = 1'
>>> exec(ast.unparse(ast.parse("𝕕𝕖𝕗 = 1")))  # SyntaxError
```

Technically, this is a bug on the fact that it breaks the only guarantee of ast.unparse:

> Unparse an ast.AST object and generate a string with code that would produce an equivalent ast.AST object if parsed back with ast.parse().

But I am not really sure if it should be handled at all, since we don't have access to the original form of the identifier in the AST due to the parser's normalization behavior.

If we want to only create a source that would give the same AST, abusing the fact that original keywords are always basic ASCII we could embed a map of characters that convert ASCII 'a', 'b', 'c', ... to their most similar unicode versions (https://util.unicode.org/UnicodeJsps/confusables.jsp). But I feel like this is a terrible idea, with no possible gain (very limited use case) and very prone to a lot of confusions. 

I think just adding a warning to the documentation regarding this should be the definite resolution, unless @pablogsal has any other idea.

I've done very little work on CPython, but I do a lot of AST construction and call `ast.unparse` a lot in my work on Hylang, and I think this is a wart worth fixing. The real mistake was letting the user say `𝕕𝕖𝕗 = 1`, but that's been legal Python syntax for a long time, so I doubt a change to that would be welcome, especially one affecting old stable versions of Python like 3.9. Python has made its bed and now it must lie in it.

I think that with a pretty small amount of code (using code-point arithmetic instead of a dictionary with every ASCII letter), I can add Unicode "escaping" of reserved words to the part of `ast.unparse` that renders variable names. Would a patch of this kind be welcome?

And yes, while this behavior will look strange, the only code that will parse to AST nodes that require it will be code that uses exactly the same trick.

'Reserved words' include all double underscore words, like __reserved__.  Using such is allowed, but we reserve the right to break such code by adding a use for the word.  'def' is a keyword.  Using identifier normalization to smuggle keywords into compiled code is a clever hack.  But I am not sure that there is an actionable bug anywhere.  

The Unicode normalization rules are not defined by us.  Changing how we use them or creating a custom normalization form is not to be done lightly.

Should ast.parse raise?  The effect is the same as "globals()['𝕕𝕖𝕗']=1" (which is the same as passing 'def' or anything else that normalizes to it) and that in turn allows ">>> 𝕕𝕖𝕗", which returns 1.  Should such identifiers be outlawed?

https://docs.python.org/3/reference/lexical_analysis.html#identifiers says "All identifiers are converted into the normal form NFKC while parsing; comparison of identifiers is based on NFKC."  This does not say when an identifier is compared to the keyword set, before or after normalization.  Currently is it before.  Changing this to after could be considered a backwards-incompatible feature change that would require a deprecation period with syntax warnings.  (Do other implementations also compare before normalization?)

Batuhan already quoted https://docs.python.org/3/library/ast.html#ast.unparse and I mostly agree with his comments.  The "would produce" part is contingent upon the result having no syntax errors, and that cannot be guaranteed.  What could be done is to check every identifier against keywords and change the first character to a chosen NFKD equivalent.  Although 'fixing' the ast this way would make unparse seem to work better succeed in this case, there are other fixes that might also be suggested for the same reason. 

Until this is done in CPython, anyone who cares could write an AST visitor to make the same change before calling unparse.  Example code could be attached to this issue.

(Hilariously, I couldn't post this comment on bugs.python.org due to some kind of Unicode bug ("Edit Error: 'utf8' codec can't decode bytes in position 208-210: invalid continuation byte"), so I've rendered "\U0001D555\U0001D556\U0001D557" as "DEF" in the below.)

Thanks for clarifying the terminology re: reserved words vs. keywords.

> The effect is the same as "globals()['DEF']=1" (which is the same as
> passing 'def' or anything else that normalizes to it) and that in
> turn allows ">>> DEF", which returns 1.

This doesn't quite seem to be the case, at least on Pythons 3.9 and 3.10:

    >>> globals()['DEF']=1
    >>> DEF
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'def' is not defined
    >>> globals()['def']=1
    >>> DEF
    1

It looks the dictionary interface to `globals` doesn't normalize like the parser does.