Skip to content

Conversation

BobTheBuidler
Copy link
Contributor

@BobTheBuidler BobTheBuidler commented Sep 18, 2025

Intent:

Mypyc can currently handle constant folding of f-strings, but mypy itself cannot.

Changes:

  • implements partial support for constant folding str.join expressions. It is a critical first step for implementing f-string support, which will come in a follow-up PR.
  • I've also implemented this for mypyc once I noticed mypyc didn't benefit from this new constant fold ability.
  • Lastly, I implemented mypyc constant folding for bytes.join, since mypy constant folding does not support bytes, it feels too similar to str.join to not do ever, and does not feel important enough for its own PR after this one.
    I can break those changes up if you'd prefer.

This comment has been minimized.

@BobTheBuidler BobTheBuidler changed the title feat: constant fold f-strings feat: partial str.join constant folding support Sep 18, 2025
@BobTheBuidler BobTheBuidler marked this pull request as ready for review September 18, 2025 21:17

This comment has been minimized.

@BobTheBuidler

This comment was marked as outdated.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@BobTheBuidler BobTheBuidler changed the title feat: partial str.join constant folding support feat: partial str.join constant folding support (and bytes.join for mypyc) Sep 25, 2025
@BobTheBuidler BobTheBuidler changed the title feat: partial str.join constant folding support (and bytes.join for mypyc) feat: str.join constant folding support (and bytes.join for mypyc) Sep 25, 2025
elif isinstance(expr, CallExpr) and isinstance(callee := expr.callee, MemberExpr):
folded_callee = constant_fold_expr(builder, callee.expr)

# builtins.str methods
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can constant fold quite a lot of cases for builtins without too much code. I have an idea for how to implement this cleanly but that's outside the scope of this PR.

This comment has been minimized.

@BobTheBuidler
Copy link
Contributor Author

I don't see any reason for this test to not fail based on the code changes. I think I might be using TupleType incorrectly here, or accessing the type in a less-than-optimal way. Any advice here would be appreciated.

Copy link
Contributor

Diff from mypy_primer, showing the effect of this PR on open source code:

graphql-core (https://github.com/graphql-python/graphql-core)
- version: 1.19.0+dev.19697af9051707b4db55bc2d5301436d872f452c
+ version: 1.19.0+dev.9ea11f958df51f70158064260d71ac32dfedf771

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant