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

[stdlib] Allow !r in String.format #3267

Closed
JoeLoser opened this issue Jul 17, 2024 · 2 comments
Closed

[stdlib] Allow !r in String.format #3267

JoeLoser opened this issue Jul 17, 2024 · 2 comments

Comments

@JoeLoser
Copy link
Collaborator

Allow "{!r}".format(x), which is equivalent to repr(x) rather than str(x). See https://dev.to/behainguyen/python-the-r-string-format-and-the-repr-and-str-methods-29i7 for more info.

@jjvraw
Copy link

jjvraw commented Jul 20, 2024

Hi :) Had a quick look into this.

Unsure of how we can allow both {!s} (inferred by {}) and {!r} without tightening the restrictions on the parameters of format, unless this is okay?

A potential solution could be to introduce a new trait, StringRepresentable, that inherits from both Stringable and Representable?

It would be neat to insert, where appropriate, the following into format:

if i == e[].field[Int]:
    if e[].conversion_flag == "r":
        res  = repr(args[i])
    else:
        res  = str(args[i])

It follows we would need to introduce this new field, conversion_flag, to _FormatCurlyEntry and adjust the logic in _FormatCurlyEntry.make_entries.

In comparison to the Formatter trait this would approach would still align more closely with Python's use of dunder methods?

If this seems like the right direction, I'm happy to continue working on a PR. If not, also happy to consider a different approach.
Found some free time and worked on a PR, which is linked below. Still happy to consider other approaches :)

On another note, if we look at the Format String Syntax from the Python docs,

replacement_field ::=  "{" [field_name] ["!" conversion] [":" format_spec] "}"
field_name        ::=  arg_name ("." attribute_name | "[" element_index "]")*
arg_name          ::=  [identifier | digit ]
attribute_name    ::=  identifier
element_index     ::=  digit  | index_string
index_string      ::=  <any source character except "]">  
conversion        ::=  "r" | "s" | "a"
format_spec       ::=  <see Python docs for details>

, it's worth mentioning that the current format implementation also omits the !a conversion.

modularbot added a commit that referenced this issue Jul 24, 2024
…3914)

[External] [stdlib] Allow `!r` conversion flag in `String.format`

This addresses #3267.

- Implemented parsing and handling of `!s` and `!r` conversion flags in
format strings.
- Updated the `_FormatCurlyEntry` struct to include a `conversion_flag`
field.
- Modified the `create_entries` method to correctly parse and store
conversion flags.
- Updated the string formatting logic to apply the appropriate
conversion (`str` or `repr`) based on the flag.

Additionally, I was conscious of potential future support of `!a` flag
and `format_spec` , which is not currently supported. The additions of
this PR should be direct to modify for this support. Hence why
`supported_conversion_flags` was added, and a TODO was left in the code
for the latter.

For reference, see [Python's Format String
Syntax](https://docs.python.org/3/library/string.html#format-string-syntax):
```
replacement_field ::=  "{" [field_name] ["!" conversion] [":" format_spec] "}"
field_name        ::=  arg_name ("." attribute_name | "[" element_index "]")*
arg_name          ::=  [identifier | digit ]
attribute_name    ::=  identifier
element_index     ::=  digit  | index_string
index_string      ::=  <any source character except "]">  
conversion        ::=  "r" | "s" | "a"
format_spec       ::=  <see Python docs for details>
```

ORIGINAL_AUTHOR=Joshua James Venter
<67124214 [email protected]>
PUBLIC_PR_LINK=#3279

Co-authored-by: Joshua James Venter <67124214 [email protected]>
Closes #3279
MODULAR_ORIG_COMMIT_REV_ID: 9ee92a55ac683be22f7b93012f37c6980f7110b6
@JoeLoser
Copy link
Collaborator Author

Fixed in #3279, thank you for the contribution!

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

No branches or pull requests

2 participants