| msg151505 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-18 00:54 |
| http://docs.python.org/py3k/library/string.html#format-specification-mini-language "The fill character can be any character other than ‘{‘ or ‘}’. The presence of a fill character is signaled by the character following it, which must be one of the alignment options. If the second character of format_spec is not a valid alignment option, then it is assumed that both the fill character and the alignment option are absent." >>> '{0:x>10d}'.format(1) 'xxxxxxxxx1' >>> '{0:xx10d}'.format(1) Traceback (most recent call last): File "", line 1, in ValueError: Invalid conversion specification >>> |
|
|
| msg151507 - (view) |
Author: Eric V. Smith (eric.smith) *  |
Date: 2012-01-18 01:15 |
| What is the expected output, and why? I think the error message might be incorrect, possibly it should be "invalid format specifier". |
|
|
| msg151510 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-18 02:06 |
| absent fill char and align option: >>> '{0:10d}'.format(1) ' 1' >>> |
|
|
| msg151523 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-01-18 08:45 |
| I'm not sure what you're saying here. Is it that 'xx' should be ignored? The documentation says that 'xx' isn't fill and alignment, not that they don't exist. If they're not fill and alignment, then the format string is in error. |
|
|
| msg151525 - (view) |
Author: Boštjan Mejak (Retro) |
Date: 2012-01-18 09:26 |
| Please fix the error message to "invalid format specifier" |
|
|
| msg151571 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-18 22:27 |
| Eric V. Smith wrote: > I'm not sure what you're saying here. Is it that 'xx' should be ignored? yes, the description says they are assumed absent |
|
|
| msg151573 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-01-18 22:52 |
| The only error is the text of the ValueError. I'll look into fixing that. These characters will not be ignored. |
|
|
| msg151576 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-18 23:00 |
| "If the second character of format_spec is not a valid alignment option, then it is assumed that both the fill character and the alignment option are absent." what does it mean ? |
|
|
| msg151577 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2012-01-18 23:04 |
| py.user: The format string must always match the grammar, which is just above the paragraph that you quoted: [[fill]align][sign][#][0][width][,][.precision][type] Thus, if fill and align are absent, it does not mean that you can add arbitrary characters like "xx". I think the docs are crystal clear; I also prefer Eric's suggestion for a new error message. |
|
|
| msg151578 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-01-18 23:10 |
| Changing to 3.3: I don't think applying this to 3.2 would be appropriate. |
|
|
| msg151580 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-18 23:15 |
| 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 alignment" |
|
|
| msg151587 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2012-01-18 23:40 |
| 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 text says. But even in your irregular case the text is still correct: After it has been established that [[fill]align] is not present you have to match the *whole string* with the rest of the grammar: [sign][#][0][width][,][.precision][type] There is no match for "xx10d", hence the error. BTW, I think this is out of scope for the tracker now. If you have further questions, you could ask on: http://mail.python.org/mailman/listinfo/python-list |
|
|
| msg151588 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-01-18 23:42 |
| 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]align][sign][#][0][width][,][.precision]", so it must be the "[type]" field. I'm open to a better message, though. Due to the variable width chars in the format_spec string, include the "xx10d" along with the error text is a little complicated. But maybe including it would be an improvement: "Invalid format type 'xx10d' found, expected a single character". |
|
|
| msg151591 - (view) |
Author: py.user (py.user) * |
Date: 2012-01-19 00:00 |
| 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 ValueError exception" thanx for the mailing list |
|
|
| msg151592 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2012-01-19 00:34 |
| Eric V. Smith <report@bugs.python.org> 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" doesn't match any of "[[fill]align][sign][#][0][width][,][.precision]", > so it must be the "[type]" field. I think this has the potential of being more confusing for people who are not very familiar with the format specification mini-language. I didn't look at the code now, but would the message also be raised for this spec? format(9, "xx10f") > I'm open to a better message, though. IMO "invalid format specifier" is fine. Even the existing error message is not really terrible. |
|
|
| msg151594 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2012-01-19 00:43 |
| Stefan Krah <report@bugs.python.org> 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. |
|
|
| msg151598 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2012-01-19 00:54 |
| 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 say: >>> format(9, "xx10f") Traceback (most recent call last): File "", line 1, in ValueError: Invalid format code |
|
|
| msg151663 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-01-20 01:04 |
| New changeset 5c33ebb50702 by Eric V. Smith in branch 'default': Improve exception text. Closes issue 13811. http://hg.python.org/cpython/rev/5c33ebb50702 |
|
|