[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: 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. -- resolution: -> fixed stage: patch review -> resolved

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: I don't have a strong feeling one way or the other. I'd be surprised if anyone is catching these errors. -- ___ Python tracker

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: 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 "", line 1, in ValueError: Unknown format code 'j' for object of type 'str' >>> format([1, 2,

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: 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. --

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: Shouldn't the type of error be changed from TypeError to ValueError? -- ___ Python tracker ___

[issue28385] Bytes objects should reject all formatting codes with an error message

Roundup Robot added the comment: New changeset f43078ec598c by Serhiy Storchaka in branch '3.6': Update the f-string test broken in issue #28385. https://hg.python.org/cpython/rev/f43078ec598c New changeset 931410a04240 by Serhiy Storchaka in branch 'default': Update the f-string test broken in

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: 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. -- ___ Python tracker

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: What is better? 1. Replace "unsupported format string passed to" back to "non-empty format string passed to " in generated error message? Note that full error message is changed in any case, this is the purpose of this issue. 2. Change the pattern

[issue28385] Bytes objects should reject all formatting codes with an error message

Ned Deily added the comment: Buildbots are failing: == FAIL: test_errors (test.test_fstring.TestCase) (str="f'{(lambda: 0):x}'") -- TypeError: unsupported

[issue28385] Bytes objects should reject all formatting codes with an error message

Roundup Robot added the comment: New changeset 92cae79fa5d9 by Serhiy Storchaka in branch '3.5': Issue #28385: An error message when non-empty format spec is passed to https://hg.python.org/cpython/rev/92cae79fa5d9 New changeset 0a985f7c6731 by Serhiy Storchaka in branch '3.6': Issue #28385: An

[issue28385] Bytes objects should reject all formatting codes with an error message

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: >From msg214162: > This is basically the definition of object.__format__: > > def __format__(self, specifier): > if len(specifier) == 0: > return str(self) > raise TypeError('non-empty format string passed to object.__format__') This simple algorithm

[issue28385] Bytes objects should reject all formatting codes with an error message

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: Removed item 3 from updated patch. -- Added file: http://bugs.python.org/file45127/object-__format__-2.patch ___ Python tracker

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: 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! -- ___ Python tracker

[issue28385] Bytes objects should reject all formatting codes with an error message

Serhiy Storchaka added the comment: Sorry, but it looks to me that issue28385.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

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: 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

[issue28385] Bytes objects should reject all formatting codes with an error message

Berker Peksag added the comment: Here's a patch. Changes in test_builtin might be redundant, but I added them anyway. -- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review Added file: http://bugs.python.org/file45011/issue28385.diff

[issue28385] Bytes objects should reject all formatting codes with an error message

Марк Коренберг added the comment: Yes, that message will be sufficient. Perfectly. -- ___ Python tracker ___

[issue28385] Bytes objects should reject all formatting codes with an error message

Eric V. Smith added the comment: Yes, I think we should implement this for object.__format__. Marking as easy. -- components: +Interpreter Core -Library (Lib) keywords: +easy (C) ___ Python tracker

[issue28385] Bytes objects should reject all formatting codes with an error message

R. David Murray added the comment: 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