This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ast.unparse-ing a FunctionType gives ambiguous result
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.10
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, cleoold
Priority: normal Keywords:

Created on 2021-03-24 02:14 by cleoold, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (4)
msg389429 - (view) Author: midori (cleoold) Date: 2021-03-24 02:14
Hi all, this is probably my first issue here, so don't blame me if I do something wrong lol

The ast.FunctionType gives syntax like (a, b) -> c for function types, this is ok, and also since Python 3.10 we can use X | Y to denote unions, this is ok. So Given the following two trees:

fun1 = ast.FunctionType(
    argtypes=[],
    returns=ast.BinOp(
        left=ast.Name(id='int'),
        op=ast.BitOr(),
        right=ast.Name(id='float'),
    )
)
fun2 = ast.BinOp(
    left=ast.FunctionType(
        argtypes=[],
        returns=ast.Name(id='int'),
    ),
    op=ast.BitOr(),
    right=ast.Name(id='float'),
)

Calling:

print(ast.unparse(fun1))
print(ast.unparse(fun2))

The results are these:

() -> int | float
() -> int | float

So there is some ambiguity. By feeding this string to ast.parse(mode='func_type'), I know that it means "returning a union".

Don't know if there is any impact to simply add a pair of parens, or does this problem even matters at all.

I tested it using Python 3.10 a6 and Python 3.9.2.
msg389519 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2021-03-25 19:05
Hey @cleoold! Technically the second AST you gave is invalid (fun2), considering that the FunctionType is not an expression;

    mod = Module(stmt* body, type_ignore* type_ignores)
        | FunctionType(expr* argtypes, expr returns)

    expr = BoolOp(boolop op, expr* values)
         | NamedExpr(expr target, expr value)
         | BinOp(expr left, operator op, expr right)

Though I am curious about use case. How did you come with the fun2's AST?
msg389523 - (view) Author: midori (cleoold) Date: 2021-03-25 19:55
@BTaskaya I've seen this in third party ides and type checker. For example they are referring to "Union[Callable[[], Union[int, str]], None]" as "() -> (int | str) | None" where there are parentheses around the returns.
msg389559 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2021-03-26 19:08
> @BTaskaya I've seen this in third party ides and type checker. For example they are referring to "Union[Callable[[], Union[int, str]], None]" as "() -> (int | str) | None" where there are parentheses around the returns.

Though you can not simple parse this and expect to get the AST you gave as an example (fun2). This would be parsed like
FunctionType(
    argtypes=[],
    returns=BinOp(
        left=BinOp(
            left=Name(id='int', ctx=Load()),
            op=BitOr(),
            right=Name(id='str', ctx=Load())),
        op=BitOr(),
        right=Constant(value=None)))

and we would roundtrip it;
>>> source = '() -> (int | str) | None'
>>> ast1 = ast.parse(source, mode='func_type')
>>> ast2 = ast.parse(ast.unparse(ast1), mode='func_type')
>>> ast.dump(ast1) == ast.dump(ast2)
True


I get what you mean (like 2 separate nodes connected with Union[]) though you can not simply parse the func_type syntax ( () -> ... ) with the normal parser, so you can't use it with binary or. It seems like this is not a bug on ourside, but rather a bug on the creator of this source (like union of func type and binary or).
History
Date User Action Args
2022-04-11 14:59:43adminsetgithub: 87775
2021-03-26 19:08:50BTaskayasetstatus: open -> closed
resolution: not a bug
messages: + msg389559

stage: resolved
2021-03-25 19:55:08cleooldsetmessages: + msg389523
2021-03-25 19:05:07BTaskayasetnosy: + BTaskaya, - Batuhan Taskaya
messages: + msg389519
2021-03-24 02:14:47cleooldcreate