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
Bytes objects should reject all formatting codes with an error message #72571
Comments
$ python3 -c "'{0:s}'.format(b'qwe')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__ Spent many hours to detect bug in my code. |
Bytes don't support formatting codes, so they are passed through to object, which doesn't support any formatting codes, and produces the error message you see. Since all other built in types reject invalid codes with a message that mentions their type, I think bytes should too. This would change the message to: ValueError: Unknown format code 's' for object of type 'bytes' Would that have lessened your confusion sufficiently? |
Yes, I think we should implement this for object.__format__. Marking as easy. |
Yes, that message will be sufficient. Perfectly. |
Here's a patch. Changes in test_builtin might be redundant, but I added them anyway. |
I left a comment on Rietveld, but repeating it here because for me those messages often go to spam: I think you want to make this more general, by modifying the message for the TypeError that follows. Any type that doesn't provide it's own __format__ should produce an error when using a non-empty format string. For example: >>> format({}, 'a')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__ Would be better as: (Or some prettier way to print out the type). |
Sorry, but it looks to me that bpo-28385.diff solves wrong issue. The issue is not in bytes, but in default __format__. object.__format__ should raise an error message that contains the name of the actual type. There are other issues with object.__format__, following patch tries to solve them.
|
LGTM, although I'm not so sure about your #3. Maybe it should be a separate issue and raised on python-dev? But I don't feel strongly enough about it to argue the point. Thanks! |
Removed item 3 from updated patch. |
From msg214162:
This simple algorithm is implemented in object-format.patch. But current implementation uses |
New changeset 92cae79fa5d9 by Serhiy Storchaka in branch '3.5': New changeset 0a985f7c6731 by Serhiy Storchaka in branch '3.6': New changeset 6e8183abcc35 by Serhiy Storchaka in branch 'default': |
Buildbots are failing: ====================================================================== During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/root/buildarea/3.6.angelico-debian-amd64/build/Lib/test/test_fstring.py", line 20, in assertAllRaise
eval(str)
AssertionError: "non-empty" does not match "unsupported format string passed to function.__format__" ====================================================================== During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/root/buildarea/3.6.angelico-debian-amd64/build/Lib/test/test_fstring.py", line 20, in assertAllRaise
eval(str)
AssertionError: "non-empty" does not match "unsupported format string passed to tuple.__format__" Ran 48 tests in 1.389s |
What is better?
|
I would change the f-string tests. I realize it's a fragile test, but it's the only way to test the strings in the exception. |
New changeset f43078ec598c by Serhiy Storchaka in branch '3.6': New changeset 931410a04240 by Serhiy Storchaka in branch 'default': |
Shouldn't the type of error be changed from TypeError to ValueError? |
TypeError is documented as "Raised when an operation or function is applied to an object of inappropriate type". I think that fits this case: you're applying some format code to a type that doesn't support it. |
But on other hand, the error depends on the value of format specifier: >>> format('abc', '')
'abc'
>>> format('abc', 'j')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'j' for object of type 'str'
>>> format([1, 2, 3], '')
'[1, 2, 3]'
>>> format([1, 2, 3], 'j')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported format string passed to list.__format__ If keep TypeError I think it would be better to restore former error message "non-empty format string". |
I don't have a strong feeling one way or the other. I'd be surprised if anyone is catching these errors. |
The proposition of making default __format__ equivalent to str() will be addressed in separate issue. Python-Dev thread: https://mail.python.org/pipermail/python-dev/2016-October/146765.html. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: