* `precision` field is a decimal integer
* clarify that stated limitations are on presentation type
rather than input value type. Especially misleading is
"precision is not allowed for integer values", since integer
value input to a format like `.1f` is fine.
* regarding max field size, replace "non-number" with "string",
which is the only non-numeric presentation type
Automerge-Triggered-By: GH:ericvsmith
Add `string.Template.get_identifiers()` method that returns the identifiers within the template. By default, raises an error if it encounters an invalid identifier (like `substitute()`). The keyword-only argument `raise_on_invalid` can be set to `False` to ignore invalid identifiers (like `safe_substitute()`).
Automerge-Triggered-By: GH:warsaw
* Improve description of 'e', 'f' and 'g' presentation types
* Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications
* Fix false statement that the alternate form is valid for Decimal
* Nitpick: remove the Harvard/Oxford comma
* Add note that the decimal point is also removed if no digits follow it, except in alternate form
Use an unique identifier for the different grammars documented using
the Sphinx productionlist markup.
productionlist markups of the same grammar, like "expressions" or
"compound statements", use the same identifier "python-grammar".
Sphinx 3 disallows having more than one productionlist markup with
the same name. Simply remove names in this case, since names are not
shown anyway. For example, fix the Sphinx 3 warning:
Doc/reference/introduction.rst:96: duplicate token description
of *:name, other instance in reference/expressions
Make the definition of the width more explicit that it includes any
extra signs added by other options.
https://bugs.python.org/issue38657
Automerge-Triggered-By: @Mariatta
* bpo-34273: Change 'Fixed point' to 'Fixed-point notation'.
The change in the mini language floating point and decimal table
is consistent with 'Exponential notation' and clarifies that we
are referring to the output notation, not an object type.
* Update string.rst
* Update string.rst
* Update string.rst
* Update string.rst
string.Formatter auto-numbering feature was added in 3.4 and there
is no versionchanged note in its documentation, making the documentation
ambiguous about which version the feature is available.
Pattern `[a-z]` with `IGNORECASE` flag can match to some non-ASCII characters.
Straightforward solution for this is using `IGNORECASE | ASCII` flag.
But users may subclass `Template` and override only `idpattern`. So we want to
avoid changing `Template.flags`.
So this commit uses local flag `-i` for `idpattern` and change `[a-z]` to `[a-zA-Z]`.
* bpo-1198569: Allow the braced pattern to be different
``string.Template`` subclasses can optionally define ``braceidpattern`` if
they want to specify different placeholder patterns inside and outside the
braces. If None (the default) it falls back to ``idpattern``.
* Various sections were pointing to the section on the string.Formatter
class, when the section on the common format string syntax is probably more
appropriate
* Fix references to various format() functions and methods
* Nested replacement fields may contain conversions and format specifiers,
and this is tested; see Issue #19729 for instance
