Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[flake8-annotations] Correct syntax for typing.Union in suggested return type fixes for ANN20x rules #16025

Merged
merged 3 commits into from
Feb 7, 2025

Conversation

dylwil3
Copy link
Collaborator

@dylwil3 dylwil3 commented Feb 7, 2025

When suggesting a return type as a union in Python <=3.9, we now avoid a TypeError by correctly suggesting syntax like Union[int,str,None] instead of Union[int | str | None].

@dylwil3 dylwil3 added bug Something isn't working fixes Related to suggested fixes for violations labels Feb 7, 2025
Copy link
Contributor

github-actions bot commented Feb 7, 2025

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

Copy link
Member

@MichaReiser MichaReiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I starred at the diff for a while but I'm not entirely sure what the root cause or what the fix is. It's probably obvious but I just don't see it 😆

@@ -1438,32 +1438,18 @@ pub fn typing_optional(elt: Expr, binding: Name) -> Expr {

/// Format the expressions as a `typing.Union`-style union.
pub fn typing_union(elts: &[Expr], binding: Name) -> Expr {
fn tuple(elts: &[Expr], binding: Name) -> Expr {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with the code so this is probably a dumb question but the the old implementation applied this function recursively. Is it correct that this is no longer needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also confused by the code that was there before... At the very least this was a problem:

            [rest @ .., elt] => Expr::BinOp(ast::ExprBinOp {
                left: Box::new(tuple(rest, binding)),
                op: Operator::BitOr,
                right: Box::new(elt.clone()),
                range: TextRange::default(),
            }),

I will try to find an MRE for the difference involving the recursion... but I can't figure out why it would be necessary.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I think the recursion is there just because they were trying to get something like:

Union[int | str | float]

which is built out of binary operations, so they had to do them one at a time.

But since we're doing:

Union[int, str, float]

we can just plop down all the elements at once.

The other confusing thing is the treatment of the empty case. An empty Union is either a SyntaxError (if you do Union[]) or a TypeError (if you do Union[()]). So that's the other difference: the modified function will produce a SyntaxError where the previous produced a TypeError. But really the function should not be called at all when you have empty elts.

I could:

  • make that the responsibility of the caller
  • change the return signature to Result
  • add a debug_assert
  • something else?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@charliermarsh if you happen to remember you're reasoning from #8885 and see that I'm missing something, please let me know 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, it's hard to recall without digging deeper. But, yes, I'm guessing it's something to do with the recursive nature of the | operator. Notice that this is very similar to the pep_604_union version above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries!

@dylwil3 dylwil3 merged commit 3a806ec into astral-sh:main Feb 7, 2025
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixes Related to suggested fixes for violations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants