Python 3.8 Constant: Support for nonexistent and other "kind" fields

[tbennun]

As kind is an optional field, it may not necessarily exist in valid AST (e.g., for numeric constants). This PR both supports this case, as well as other string kinds, such as 'b' (see https://github.com/python/cpython/commit/10f8ce66884cd7fee2372b8dae08ca8132091574)

[isidentical]

Can you post an example for generating a Constant with kind other then "u" (with ast.parse)

[tbennun]

@isidentical currently, according to the above commit, this is planned but (also according to the commit) not parsed. This is unfortunate, since it requires to do type checking in an AST, which ideally should not be the case. See example below:

>>> ast.dump(ast.parse("""u"aaa" """))
"Module(body=[Expr(value=Constant(value='aaa', kind='u'))], type_ignores=[])"

>>> ast.dump(ast.parse("""b"aaa" """))
"Module(body=[Expr(value=Constant(value=b'aaa', kind=None))], type_ignores=[])"

[isidentical]

I'm aware of the u prefix behavior, but I dont see any reason to use b prefix and any activity on that.

[tbennun]

well, there has to be a reason why the prefix is a string rather than a boolean.

[isidentical]

I can't see any for now, I guess this change depends on the maintainer.

[tbennun]

@isidentical To see my reasoning, and also just for fun, try the following code: ast.unparse(ast.Constant(value=b"bad", kind="u")) This is perfectly valid Python AST. It results in "ub'bad'\n", and that is not correct python syntax.

[isidentical]

This is a manually constructed node, so if you give malformed AST you get malformed output it is pretty normal.

[simonpercivall]

Closing without action. See #43 for rationale.