Python AST deprecations

[akaihola]

In my CI build, I'm getting these deprecation warnings from Python 3.12:

  lib/python3.12/site-packages/astor/op_util.py:92: DeprecationWarning:
    ast.Num is deprecated and will be removed in Python 3.14; use ast.Constant instead
    precedence_data = dict((getattr(ast, x, None), z) for x, y, z in op_data)

  lib/python3.12/site-packages/flynt/utils/utils.py:74: DeprecationWarning:
    ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead
    ) -> Union[ast.FormattedValue, ast.Str]:

  lib/python3.12/site-packages/flynt/transform/format_call_transforms.py:22: DeprecationWarning:
    Attribute s is deprecated and will be removed in Python 3.14; use value instead
    string = fmt_call.func.value.s

  lib/python3.12/ast.py:407: DeprecationWarning:
    visit_Str is deprecated; add visit_Constant
    return visitor(node)

[ikamensh]

Thanks for reporting!
hm, it seems ast.Str and ast.Num and perhaps other nodes will be all merged into ast.Constant. Naively replacing ast.Str with ast.Constant leads to errors in flynt.

Unfortunately I couldn't find a solution to suppress these warnings either, they are no issue for users until they start using python3.14, so if I could I'd just supress warnings until then.

[akaihola]

This currently blocks akaihola/darker#774 from enabling CI tests with Python 3.14-dev.

[ikamensh]

Ok python 3.14 is on the horizon now, so this gains in importance. PR would be welcome.

[akaihola]

I'll try and come up with a PR.

Naively replacing ast.Str with ast.Constant leads to errors in flynt.

Could you expand on that? In ast — Abstract Syntax Trees — Python 3.13.1 documentation I see:

Deprecated since version 3.8: Old classes ast.Num, ast.Str, ast.Bytes, ast.NameConstant and ast.Ellipsis are still available, but they will be removed in future Python releases. In the meantime, instantiating them will return an instance of a different class.

And indeed, at least on Python 3.12:

$ python -c 'import ast; print(ast.Str())'
<string>:1: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead
<ast.Constant object at 0x7f1bdb12df50>

So what would be the case in which changing ast.Str to ast.Constant would change behavior in Python 3.8+?

[ikamensh]

isinstance(x, ast.Str) should roughly translate as isinstance(x, ast.Constant) and isinstance(x.value, str), however when I tried this replacement some cases didn't work at first. I have to say I've spent little time on it though. Perhaps if you go one by one in finding usage of deprecated classes you will find solution for each case. I'd say unless you have reason to suspect otherwise we can assume test suite coverage to be enough, so if you change classes and tests still pass it should be good to go.

It will also be good if it comes as series of PRs, you can leave complicated cases (if any) for later.

[akaihola]

Also astor doesn't seem to yet support the changes to ast in Python 3.14, so the suggested migration from astor to ast.unparse() needs to be done in ast_to_string().

Tests then need to be fixed to expect double quotes instead of single quotes.

[akaihola]

migration from astor to ast.unparse() needs to be done in ast_to_string()

...and support for Python 3.8 (end-of-life currently) needs to be dropped.

[akaihola]

expect double quotes instead of single quotes

@ikamensh is it ok if the behavior of Flynt changes with regard to single and double quotes when moving from astor to ast.unparse()?

[ikamensh]

Can you give some examples? The prob is if it gives big change list on projects already having flynt as linter. You can see projects in "used by" and run new version on their code. If it changes every other file, it can be quite annoying.

[ikamensh]

I can imagine behavior change via minor version bump, if new behavior is sensible