[mypyc] Introduce FormatOp and add a tokenizer for .format() call #10935
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
97littleleaf11
changed the title
JukkaL
reviewed
Aug 6, 2021
| format_ops = [] | ||
| for spec in specifiers: | ||
| # TODO: Match specifiers instead of using whole_seq | ||
| if spec.whole_seq == '%s' or spec.whole_seq == '{:{}}': |
There was a problem hiding this comment.
What about %d? Will it be supported in a follow-up PR?
It would be better to make this generic over different kinds of formatting instead of special casing percent sign formatting, etc. Do you plan to improve this in a follow-up PR (I assume that this is what the TODO comment is about)?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a tokenizer that convert a str.format() format string into literals and specifiers. By doing so, the code structure of
translate_str_formatis clearer.This PR also introduces
FormatOp. Compare toConversionSpecifier,FormatOphas fewer attributes and indicates compile time optimizations. For example, to mark a conversion from any object to string,ConversionSpecifiermay have several representations, like '%s', '{}' or '{:{}}'. However, there would only exist one correspondingFormatOp.Currently
FormatOpis just an Enum for convenience. We might add several attributes later and upgrade it to a class if we need to support more conversions.To help for the future optimization, these parts of code are extracted into new functions:
generate_format_opsthat shrinkConversionSpecifierintoFormatOpconvert_exprthat can help convert the expressions into desired results.