I first raised this issue on Stack Overflow: http://stackoverflow.com/questions/19203194

The [replacement field grammar][1] states that an [integer][2] is a valid field_name, but this is inaccurate:

    >>> '{0}'.format('zero')
    'zero'
    >>> '{0x0}.format('zero')
    KeyError: '0x0'
    >>> '{0o0}.format('zero')
    KeyError: '0o0'
    >>> '{0b0}.format('zero')
    KeyError: '0b0'

This [comment][3] by Eric Smith suggests that the above is the intended behaviour:

> get_integer uses the narrowest possible definition for integer indexes,
> in order to pass all other strings to mappings.

The documentation should be updated to match the actual behaviour. abarnert on Stack Overflow suggested the following change:

    -arg_name          ::=  [identifier | integer]
    +arg_name          ::=  [identifier | digit+]


[1]: http://docs.python.org/2/library/string.html#format-string-syntax
[2]: http://docs.python.org/2/reference/lexical_analysis.html#grammar-token-integer
[3]: http://bugs.python.org/issue8985#msg107705

The bug is that "integer" links to the "integer" production in the Python grammar.  This shouldn't happen; I'll have a look on the Sphinx side.

As a workaround, "integer" can be replaced by "digit+" as requested (it occurs twice).