In Python 3.8, the "kind" field was introduced into the Constant AST class. This brings about a problem when unparsing the AST for various packages. First, it breaks backward compatibility for older code that creates ast.Num without specifying kind (which is optional anyway and does not exist in its fields). Second, since bytes are parsed as a Constant without a kind, one can create the following (valid as of now) AST and unparse it:

ast.unparse(ast.Constant(value=b"bad", kind="u"))

Getting "ub'bad'", which is invalid Python syntax AFAIU.

Could something be done with the classes that extend ast.Constant and with bytes being a Constant with a "kind" of "b"?

Origin of this thread: https://github.com/simonpercivall/astunparse/pull/44

> First, it breaks backward compatibility for older code that creates ast.Num without specifying kind 

The ast changes during versions, and in the current master there are no "Num" nodes, so not much we could do there sadly.

>Second, since bytes are parsed as a Constant without a kind, one can create the following (valid as of now) AST and unparse it:

You can create multiple malformed ast objects that will crash the interpreter if you pass it to `compile` or other functions that expect a valid AST. Passing invalid AST objects to these functions is out of contract (also, sanitizing that an AST is valid will make this functions much slower and will be a lot of code to maintain and CPython itself will not benefit much from it).

Maybe we need to clarify to the docs of 'unparse' that the AST object needs to be valid.

> Maybe we need to clarify to the docs of 'unparse' that the AST object needs to be valid.

As I stated earlier, constant tuple like things are valid but don't fit on description. Maybe we should only offically allow things that can be generated by ast.parse? We can still implement support for constant tuples etc but we shouldnt have to check malformed ast.

> Maybe we should only offically allow things that can be generated by ast.parse?

Yes, I think this is the way to go. In the future, we can expand the function to support more things, but for the first release, it should be as much restrictive as possible so we can iterate safely without making backwards-incompatible changes. 

I will update the docs soon to reflect this.

We added the warnings, and I believe we can close this safely (since there is no intend to change the behavior of ast.unparse)