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 "<stdin>", line 1, in <module>
ValueError: Invalid conversion specification
>>>

What is the expected output, and why?

I think the error message might be incorrect, possibly it should be "invalid format specifier".

absent fill char and align option:

>>> '{0:10d}'.format(1)
'         1'
>>>

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.

Please fix the error message to "invalid format specifier"

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

The only error is the text of the ValueError. I'll look into fixing that. These characters will not be ignored.

"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 ?

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.

Changing to 3.3: I don't think applying this to 3.2 would be appropriate.

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"

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

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".

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

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.

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.

The existing exceptions use the text "format code" for what the documentation calls "type":

>>> format(9, "h")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
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 "<stdin>", line 1, in <module>
ValueError: Invalid format code

New changeset 5c33ebb50702 by Eric V. Smith in branch 'default':
Improve exception text. Closes issue 13811.
http://hg.python.org/cpython/rev/5c33ebb50702