Unknown name "kind" on Constant for Python 3.7

[spenczar]

The kind attribute was added to the Constant expression in AST in Python 3.8. See https://bugs.python.org/issue36280.

That means that in Python 3.7's ast module, Constants never have a kind, so this line always errors.

While unparse has made it in to Python 3.9's ast module, I'd really like to use astunparse as a sort of backport. It's still useful while Python 3.7 and 3.8 are in heavy use!

[pastelmind]

I am not a contributor, but I believe ast.parse() does not produce ast.Constant() until 3.8. I assume your code will have to avoid ast.Constant() to keep compatibility with 3.7.

[spenczar]

What do you suggest as an alternative for representing literal values, @pastelmind? After 3.8, ast.parse() does not produce ast.Num() or ast.String() etc.

This seems fixable directly in astunparse instead - I'll draft a patch.

[pastelmind]

I did a sys.version_info() < (3, 8) check to produce/handle ast.Num() and ast.Str() on Python < 3.8; while only handling ast.Constant() on Python 3.8+.

How are you generating AST trees from code? If your code runs in Python < 3.8, it shouldn't see ast.Constant at all.

[spenczar]

I am generating ASTs directly, not sourced from code, for example here: https://github.com/spenczar/avroc/blob/main/avroc/codegen/write.py#L289

I am compiling Avro data schema definitions into code objects. I use astunparse to populate the Python interpreter’s linecache so that stack traces work correctly (https://github.com/spenczar/avroc/blob/main/avroc/codegen/compiler.py#L86).

I guess I could have switches in the code generator based on the Python version, but that seems pretty annoying to keep up with. astunparse could check if the kind attribute exists on the Constant object before using it.