[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Roundup Robot added the comment: New changeset 5c33ebb50702 by Eric V. Smith in branch 'default': Improve exception text. Closes issue 13811. http://hg.python.org/cpython/rev/5c33ebb50702 -- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open ->

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Eric V. Smith added the comment: The existing exceptions use the text "format code" for what the documentation calls "type": >>> format(9, "h") Traceback (most recent call last): File "", line 1, in ValueError: Unknown format code 'h' for object of type 'int' So to be consistent, it should

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Stefan Krah added the comment: Stefan Krah wrote: >> ["xx10d"] > look at the code now, but would the message also be raised for this spec? > > format(9, "xx10f") Argh, 'd' is of course also a valid type specifier. -- ___ Python tracker

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Stefan Krah added the comment: Eric V. Smith wrote: > As I look at it a little closer, I think I'm going to change the message to: > "Invalid format type specified". The code has determined that instead of a > type that's a single character long, it's received "xx10d". That's because > "xx" doe

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

py.user added the comment: Stefan Krah wrote: > After it has been established that [[fill]align] is not present you have to > match the *whole string* with the rest of the grammar I think, there should be a text in the documentation: "if the alignment optiont is invalid, it will be raised a V

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Eric V. Smith added the comment: As I look at it a little closer, I think I'm going to change the message to: "Invalid format type specified". The code has determined that instead of a type that's a single character long, it's received "xx10d". That's because "xx" doesn't match any of "[[fill

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Stefan Krah added the comment: The text speaks about the regular case of a second character that is not a valid alignment character, e.g.: format(3.222, ".2f") Clearly the '2' fulfills this criterion, so the parser knows that the leading '.' is *not* a fill character. This is all that the

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

py.user added the comment: Stefan Krah wrote: > Thus, if fill and align are absent, it does not mean that you can add arbitrary characters like "xx". the descriptions says in other words: "if you have used an incorrect alignment option, then the interpreter behaves like you didn't use fill and

[issue13811] In str.format, if invalid fill and alignment are specified, the text of the ValueError message is misleading.

Eric V. Smith added the comment: Changing to 3.3: I don't think applying this to 3.2 would be appropriate. -- assignee: -> eric.smith keywords: +easy priority: normal -> low stage: -> needs patch title: In str.format an incorrect alignment option doesn't make fill char and onself abs