Terminology. Let's use the official terminology rather than making stuff up.

The docs at http://docs.python.org/3/library/string.html#formatspec
use the following terminology:

Replacement field: {...}; contains field name, conversion, format spec
in that order, all optional.

Field name: either a decimal integer (referring to an argument by
position) or an identifier (by name), or omitted (uses the next
available position).

Conversion: !r, !s, !a; these refer to repr(), str(), ascii() to the
value, and then the format spec applies to the resulting string.

Format spec: colon, bunch of stuff, type; the type is a letter such as
d (decimal) or s (string), and the stuff between the colon and the
type is used to specify field width, alignment, sign, padding and
such.


Also. {:b} means binary (i.e. numbers in base 2). I'm not sure what
this leaves for interpolating bytes if we don't want to use {:s}. The
docs at http://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting
don't show %b so it could still be used there, but it would be nicer
to be consistent.

I have been going on the assumption that bytes.format() would change what '{}' meant for itself and would only interpolate bytes. That convenient between Python 2 and 3 since it represents what we want it to (str and bytes under the hood, respectively), so it just falls through. We could also add a 'b' conversion for bytes() explicitly so as to help people not accidentally mix up things in bytes.format() and str.format(). But I was not suggesting adding a specific format spec for bytes but instead making bytes.format() just do the .encode('ascii') automatically to help with compatibility when a format spec was present. If people want fancy formatting for bytes they can always do it themselves before calling bytes.format().
">

(original) (raw)




On Mon, Jan 13, 2014 at 4:51 PM, Guido van Rossum <guido@python.org> wrote:
Terminology. Let's use the official terminology rather than making stuff up.

The docs at http://docs.python.org/3/library/string.html#formatspec
use the following terminology:

Replacement field: {...}; contains field name, conversion, format spec
in that order, all optional.

Field name: either a decimal integer (referring to an argument by
position) or an identifier (by name), or omitted (uses the next
available position).

Conversion: !r, !s, !a; these refer to repr(), str(), ascii() to the
value, and then the format spec applies to the resulting string.

Format spec: colon, bunch of stuff, type; the type is a letter such as
d (decimal) or s (string), and the stuff between the colon and the
type is used to specify field width, alignment, sign, padding and
such.


Also. {:b} means binary (i.e. numbers in base 2). I'm not sure what
this leaves for interpolating bytes if we don't want to use {:s}. The
docs at http://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting
don't show %b so it could still be used there, but it would be nicer
to be consistent.

I have been going on the assumption that bytes.format() would change what '{}' meant for itself and would only interpolate bytes. That convenient between Python 2 and 3 since it represents what we want it to (str and bytes under the hood, respectively), so it just falls through. We could also add a 'b' conversion for bytes() explicitly so as to help people not accidentally mix up things in bytes.format() and str.format(). But I was not suggesting adding a specific format spec for bytes but instead making bytes.format() just do the .encode('ascii') automatically to help with compatibility when a format spec was present. If people want fancy formatting for bytes they can always do it themselves before calling bytes.format().