str-bytes-safe with new Formatted string literals

[beauxq]

with this code:

f"{b'def'}"

I get this from mypy:

On Python 3 '{}'.format(b'abc') produces "b'abc'", not 'abc'; use '{!r}'.format(b'abc') if this is desired behavior [str-bytes-safe]

That message doesn't make it clear whether there's any issue with my code, because it's about a different string formatting.
And if it is an issue, it doesn't tell me what formatted string literal to use if this is desired behavior.

[sobolevn]

Should be fixed in 0.920 (or in 0.930). Works correctly on master:

[beauxq]

That still doesn't make sense for an output message.
How is someone supposed to use "{!r}" with bytes in a formatted string literal?
We're not formatting b'abc' with {}, because the bytes are inside the curly braces.

[sobolevn]

Any suggestions?

[beauxq]

What is the code that you would suggest someone replace this with, if they want the output that this gives?

b = b'abc'
s = f"{b}"
print(s)

[beauxq]

I think my suggestion would be that [str-bytes-safe] only applies to this:

"{}".format(b)

and should not say anything about this:

f"{b}"

[Syndace]

Why is this closed? I still don't know how to avoid the warning if I want to keep using f-strings.

Also why does the warning exist in the first place, I'd expect bytes to be printed as the b"..." honestly and it seems weird for a type checking tool to warn me about how formatting works.

[ajkaijanaho]

This error message is completely unclear and unactionable.

[sobolevn]

@ajkaijanaho do you have suggestions on how to improve it? :)

[ikonst]

@Syndace It has a distinct error code str-bytes-safe so you can disable it.

This should illustrate how to take the action on this error:
https://mypy-play.net/?mypy=latest&python=3.11&gist=097c14bfe36a2f09487802689904d5f0

@sobolevn I think 'abc' might be confusing, would be nicer if we could "unparse" the user's actual expression there. For example, in my playground that'd be:

-main.py:3: error: On Python 3 formatting "b'abc'" with "{}" produces "b'abc'", not "abc"; use "{!r}" if this is desired behavior  [str-bytes-safe]
-main.py:5: error: On Python 3 formatting "b'abc'" with "{}" produces "b'abc'", not "abc"; use "{!r}" if this is desired behavior  [str-bytes-safe]
+main.py:3: error: On Python 3 formatting "data" with "{}" produces "b'...'", not "..."; use "{!r}" if this is desired behavior  [str-bytes-safe]
+main.py:5: error: On Python 3 formatting "{data}" produces "b'...'", not "..."; use "{data!r}" if this is desired behavior  [str-bytes-safe]

Another thought would be to remove "On Python 3" since I think we're sufficiently far from Python 2.

[ajkaijanaho]

@ajkaijanaho do you have suggestions on how to improve it? :)

I do not understand it, so no. It is not clear to me why it is something that needs to be flagged by mypy, and what problem it solves. Certainly, in the context of where I ran into it, the message was incomprehensible, and Googling came up with no useful documentation (but it did turn up this issue).

I think 'abc' might be confusing, would be nicer if we could "unparse" the user's actual expression there. For example, in my playground that'd be:

Yes, this makes it clearer, but it does not answer what the recommended action is if that is not the desired behavior.

[beauxq]

This rule was made as a result of transitioning from Python 2 to Python 3.

f-strings (https://peps.python.org/pep-0498/) never existed in Python 2.

There's no reason for this rule to say anything about f-strings.

[beauxq]

Another thought would be to remove "On Python 3" since I think we're sufficiently far from Python 2.

I think removing "on Python 3" would make it MORE confusing, because that would remove context of why the rule exists.
This rule is only relevant in a transition from Python 2 to Python 3.

There are still some people migrating code bases from Python 2 to Python 3. For those people, this rule could help catch an error.

For anyone else, this rule is irrelevant - as pointed out above:

#11806 (comment)

Also why does the warning exist in the first place, I'd expect bytes to be printed as the b"..." honestly and it seems weird for a type checking tool to warn me about how formatting works.

#11806 (comment)

It is not clear to me why it is something that needs to be flagged by mypy, and what problem it solves.

This rule is just not relevant outside of a transition from Python 2 to Python 3.
If you think we're sufficiently far from Python 2, that means it's time to remove this rule from mypy.

[ikonst]

In a pure Python 3 context, a helpful error message might be something that outlines your options e.g.

"{data}" (or equivalent "{}".format(data)) is implicitly getting a repr of the bytes.

• If that's your intention, make it explicit by adding !r to the format string.
• If you meant to decode the bytes to str, call data.decode().

Now, whether "printing bytes as if they were a string" is a likely error (especially for devs who didn't come from py2) or mypy nannying the developer is one that's hard to answer. I do think adding !r better complies with "explicit is better than implicit" :)