3.x str.format() format strings denote replacement fields with braces
{}. Currently, replacement fields *must* contain "either the numeric
index of a positional argument, or the name of a keyword argument". [lib
ref / builtin types / sequence types / string methods /str.format()]

For simple sequential positional replacements, such as:
  "{0} is {1} {2}".format('Numbering fields', 'an annoying', 'nuisance')
the writer has to do what computers are so good at, counting, and what
was *not* required with % interpolation, where one could write more simply
  "%s is %s %s" % (('Auto-numbering', 'a convenient', 'feature')
.
Proposal: Allow field names to be omitted for all fields in a string and
then default to 0, 1, ... so one could also write 
  "{} is {} {}".format('Auto-numbering', 'a convenient', 'feature'

This proposal is currently all or nothing for simplicity of description
and presumed ease of implementation.  The patch to the doc could then be
  "If all replacement fields are left blank, then sequential indexes 0,
1, ... will be automatically inserted."
inserted after the phrase quoted above.  Mixing blank and non-blank
specs would then be an error and raise an exception.

This idea was posted today on Python-ideas thread "String formatting and
named tuple".  So far, +1 from Aahz, Raymond Hettinger, and Mathias
Panzenbock.

It's easy enough to implement. Although the 'all-or-nothing' aspect is a
little tough, I'll have to give it some thought.

Maybe the best way to do this is to first create a string.Formatter
subclass that implements it. I'll play with it and see what I come up with.

From the description, I'm presuming we'd want:
'{d}{s}{f}'.format(3, 'foo', 3.14)
to work.

'{d}{s}{f}'.format(3, 'foo', 3.14)

is possibly unclear,
but is shorter than

'{#d}{#s}{#f}'.format(...)

I am net yet fluent in format method.  I meant

":" where "#" appeared.

Anyway, I think you need the colon. 
 
If from
print('{0:9}'.format(33))

you make the argument number implicit and remove the colon you'd get

print('{9}'.format(33))

which does and should raise IndexError.

How is:
'{d}{s}{f}'.format(3, 'foo', 3.14)

more unclear than:
'%d%s%f' % (3, 'foo', 3.14)
?

But the more I think about it, the more I think it would have to be:
'{:d}{:s}{:f}'.format(3, 'foo', 3.14)
Since "{0:0}" is a legitimate format string, I need some way to tell
whether "{0}" is missing the positional parameter or is missing the
format specifier.

+1 for the general idea from me too, assuming that all the details can
be worked out in a sane manner.

Is it worth opening a discussion about this on comp.lang.python?

The attached file is a mostly working version that inherits from
string.Formatter. It has the following shortcomings, which would all be
addressed if we go forward:

- Doesn't handle escaping '{' or '}'
- Doesn't handle conversion specifiers, like '!s'

These are all a function of me being too lazy to write a complete
parser. If anyone really wants them, I could add them. But this is just
a proof of concept.

Admittedly this isn't a drop-in replacement for ''.format(), but it
should give a taste of what using it would be like.

Unfortunately, `'{d}{s}{f}'.format(3, 'foo', 3.14)` can't work as you
expect it to, because it already means "display the keyword arguments
named `d`, `s` and `f`.

(I agree that the syntax for format() strings is exceedingly tedious)

On the other hand, `'{:d}{:s}{:f}'.format(3, 'foo', 3.14)` should be
possible.

Answering first question msg81873.

Without colon separator, this might be considered confusing:

>>> (
...     '{d}{s}{f}{f}'.format(3, 'foo', 3.14, 2.72),
...     '{d}{s}{f}{f}'.format(d=3, s='foo', f=3.14)
... )
('3foo3.1400002.720000', '3foo3.143.14')

Right. The colon would be required if there's a format specifier. Or an
exclamation if there's just a conversion specifier:

"{!r}{:f}{!s:^10}".format('foo', 3, 10)
would give:
"'foo'3.000000    10    "

I've attached a new version that includes format specifiers.

All I am requesting is that
'{} {} {}'.format(3, 'pi', 3.14) work as

>>> '%s %s %s' % (3, 'pi', 3.14)
'3 pi 3.14'
>>> '{0} {1} {2}'.format(3, 'pi', 3.14)
'3 pi 3.14'

do today (3.0).

I should note that the difference between typing {}, which is easy, and
{1}, is more than just one keystroke because the latter requires
unshift-1-shift

Terry J. Reedy wrote:
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
> 
> All I am requesting is that
> '{} {} {}'.format(3, 'pi', 3.14) work as
> 
>>>> '%s %s %s' % (3, 'pi', 3.14)
> '3 pi 3.14'
>>>> '{0} {1} {2}'.format(3, 'pi', 3.14)
> '3 pi 3.14'
> 
> do today (3.0).

My string.Formatter subclass (attached to this bug report) does do this:

$ ./python.exe 
Python 2.7a0 (trunk:69516, Feb 11 2009, 14:30:31) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from auto_number_formatter_1 import MyFormatter
>>> f = MyFormatter()
>>> f.format('{} {} {}', 3, 'pi', 3.14)
'3 pi 3.14'
>>> 

This is just for vetting the concept, if it's accepted I'll modify
''.format(). It's not a huge change. I just want to make sure that this
implements what people are expecting.

The talk about '{:d}' and the like is just to make sure all the cases
are addressed. I doubt it would often be used that way.

> I should note that the difference between typing {}, which is easy, and
> {1}, is more than just one keystroke because the latter requires
> unshift-1-shift

Agreed.

auto_number_formatter_2.py lets you experiment with this with a syntax
more similar to what ''.format() looks like:

$ ./python 
Python 2.7a0 (trunk:69608, Feb 14 2009, 04:51:18) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from auto_number_formatter_2 import formatter as _
>>> _('{} {} {}').format(3, 'pi', 3.14)
'3 pi 3.14'
>>> 

It still doesn't handle escaping '{' and '}', but is otherwise complete.
If the consensus is that this is useful, I'll implement it in
''.format(), otherwise I'm done with this issue.

Okay, one last version. This one lets you use object access within the
replacement string:

>>> from auto_number_formatter_3 import formatter as _
>>> _('{} {} {}').format(3, 'pi', 3.14)
'3 pi 3.14'
>>> _('{:#b} {!r:^10} {.imag}').format(3, 'pi', 3j+1)
"0b11    'pi'    3.0"

So not it lets you add in format specifiers, conversion specifiers, and
object access. At this point the improvement of leaving out the index
numbers is less clear. I'll leave it for debate if this is useful. I
think it probably is, if only because it's easier to explain the
behavior: If you leave out the 'field name', a sequential number is
added in front of the 'replacement string' (using PEP 3101 nomenclature).

I'm attaching a patch that delivers the basic functionality in
str.format. This patch is against trunk, although it will probably work
elsewhere.

DO NOT USE THIS PATCH IN ANY SERIOUS WORK

It doesn't implement all of the needed functionality, it probably has a
memory leak, and it most likely can cause a GP fault. It does, however,
handle the common cases and it will give you a taste of the feature.

In particular, it doesn't handle anything other than empty braces
('{:d}' will fail). I can add this, and I think it should be added, but
I just haven't had the time to finish it up. I wanted to get this posted
so others can play with it and we can reach a decision if we want to add
this functionality. Personally, I think it's a great improvement, and
the more I play with it the more I like it.

If we reach a consensus that the feature should be added, I can probably
get it cleaned up and finished before PyCon.

$ ./python.exe 
Python 2.7a0 (trunk:70244M, Mar  8 2009, 16:54:23) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{} {} {}'.format(1, 3.4, 'test')
'1 3.4 test'
>>> '{} {1}'.format(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot switch from automatic field numbering to manual field
specification
>>>

Also note that this patch causes a few tests to fail, since they're
trying to ensure that '{}'.format will fail. If we go forward I'll
address that too, of course.

Please go ahead and finish this. I'm glad this is going in!

Excellent feature - with this, I would actually see some hope for
dropping all of my remaining uses of %-formatting at some point in the
future.

Would someone like to point the python-ideas discussion which
rationalizes this request?
And what would be written in the documentation? As much as I
understand this, emptry braces {} for replacement fields is kind of
unseen and leaves much thinking if this can be simplified, just as %
or # or any other character instead of a opening { and closing }.

http://mail.python.org/pipermail/python-ideas/2009-February/002873.html

Terry covered how to document the feature in his original description of
the proposal. After the phrase "either the numeric
index of a positional argument, or the name of a keyword argument." in
the docs, add a sentence along the lines of the following:

  "If the index/name is left out for all replacement fields, then the
sequential values 0, 1, ... will be automatically inserted."

It may also be worth explicitly stating the following in the docs: "Note
that automatically numbered and explcitly namged/numbered replacement
fields cannot be mixed in a single format string". (This could probably
be relegated to a footnote).

This proposal is also significantly better defined than the rather
bizarre behaviour seen in the equivalent situation with %-formatting:

>>> "%s %(name)s" % dict(name="Hmm")
"{'name': 'Hmm'} Hmm"

>>> "%s %(name)s %s" % dict(name="Hmm")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string

>>> "%s %(name)s %s" % (dict(name="Hmm"), "dodgy")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format requires a mapping

I'm thinking of allowing you to mix keywords and auto-numbering, but not
manual numbering and auto-numbering. This would be so we could do:

>>> '{:{fmt}} {:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f')
'pi=3.1415 e=2.7183'

Unfortunately the ':' is required, because if it's not there you have 2
braces next to each other, which is the escape sequence for a single brace.

Copy and paste error. That should be:

>>> 'pi={:{fmt}} e={:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f')
'pi=3.1415 e=2.7183'

Should string.Format also support auto-numbering?

It seems like it should, but I'm not convinced it's possible without
modifying the signatures to the public methods, in particular
get_field(). The design of string.Format doesn't support state that is
created in format() or vformat() and is passed in to get_field(). I
could use object state in the string.Format instance, but that doesn't
work well, due to the fact that format() can be called multiple times
per instance lifetime. string.Format really needs to have no state of
its own, for example in the case where a single instance is being used
by multiple threads or if it calls the same instance of itself
recursively. I'm going to punt on this for now.

Not sure if that's worth it -- doesn't sound like the people who would
need that feature would mind much using explicit numbering. Let's try KISS.

(I meant that as a reply to the {:{fmt}} example, but it applies to your
later post too. :-)

I believe this patch is complete. I need to add tests and documentation,
but the code itself should be finished.

Here's the normal case:
>>> '{} {}'.format('test', 0)
'test 0'

It also handles error checking:
>>> '{1} {}'.format('test', 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot switch from manual field specification to automatic
field numbering
>>> '{} {1}'.format('test', 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot switch from automatic field numbering to manual field
specification

You can use named fields along with auto-numbered fields:
>>> '{test} {}'.format(1, test=2)
'2 1'

You can nest either named or auto-numbered fields:
>>> '{:^{}}'.format('x', 10)
'    x     '
>>> 'pi={:{fmt}} {:{fmt}}'.format(3.1415, 2.71828, fmt='1.4f')
'pi=3.1415 2.7183'

Attribute access is supported:
>>> '{.__abs__}'.format(0)
"<method-wrapper '__abs__' of int object at 0x85db8f8>"

As is subscripting:
>>> '{[x]}'.format({'x':4})
'4'
>>> '{[1]}'.format([1, 2])
'2'

I'll work on the tests over the weekend, then commit to trunk and py3k.

We need to decide what to do about string.Formatter (which I just
realized I erroneously called string.Format in the previous message).

About '{:{fmt}}' and other wacky combinations, like '{.__doc__}':

It's much easier and cleaner in the code to allow these cases than it
would be to disallow them. And I rather like the '{:{fmt}}' example!

I suggest leaving them in. They might be useful, and it makes the
implementation cleaner. I think it will be easier to document, as well.
There are no special cases to describe: If the field name is omitted,
it's auto-numbered with a sequential index number. You can't mix
auto-numbering and manual specification of indexes.

As for string.Formatter, I agree we should leave it alone. I'd be
surprised if anyone is actually using it, anyway. But I'd love to hear
otherwise.

> About '{:{fmt}}' and other wacky combinations, like '{.__doc__}':
>
> It's much easier and cleaner in the code to allow these cases than it
> would be to disallow them. And I rather like the '{:{fmt}}' example!
>
> I suggest leaving them in. They might be useful, and it makes the
> implementation cleaner. I think it will be easier to document, as well.
> There are no special cases to describe: If the field name is omitted,
> it's auto-numbered with a sequential index number. You can't mix
> auto-numbering and manual specification of indexes.

OK, if allowing it is simpler, I'm all for allowing it! (I thought it
would be extra work. Shame on me for not looking at the code. :-)

> As for string.Formatter, I agree we should leave it alone. I'd be
> surprised if anyone is actually using it, anyway. But I'd love to hear
> otherwise.

OK.

Only Formatter.format_field() is particularly hard to override at the
moment (for the same reason that __format__() methods are tricky to
write). That said, creating a locale aware version of string formatting
based on string.Formatter is such an obvious idea that I would actually
be surprised if someone *hasn't* done it by now (they may not have
published it anywhere, but I expect someone has implemented it for their
own use).

That said, I think it's OK for string.Formatter to lag the actual
str.format implementation when it comes to features like this. I see it
as similar to the formatting mini-language parser problem: the primary
goal is to have a good implementation and syntax for str.format, while
providing the tools to allow people to create alternative formatters
with similar power is secondary.

Committed:
r70364 (trunk)
r70366 (py3k)

The docs still need updating. If anyone with more knowledge of the
documentation system than I have would like to tackle those, please feel
free!

Either Brandl or Peterson can and typically will change the .rst source
if given the exact new text.  For me to write that, I need to know the
grammar you actually implemented.  Did you, in essence, simply change

field_name        ::=  (identifier | integer) ("." attribute_name | "["
element_index "]")*

to (in essence)

field_name        ::=  (identifier | integer | ) ("." attribute_name |
"[" element_index "]")*

with the proviso that integers and blanks not be mixed in the same
string, so that{.attr} and {[dex]} become legal?  Or are those still
illegal because only totally blank field names are allowed, so that the
new field_name rule is essentially

field_name        ::=  ((identifier | integer) ("." attribute_name | "["
element_index "]")*) | ( )

(with the same proviso).

The existing doc text after the grammar box is slightly ambiguous or
contradictory in that it first says that field names *are* ints or names
and then says, correctly, that they *begin* with an int or name. (I
would like to fix this in addition to adding a sentence.) Hence 'blank
field name' can have two slightly different meanings and hence the
question above.

I implemented this one:
field_name        ::=  (identifier | integer | ) ("." attribute_name |
"[" element_index "]")*

Which I would have written as:
field_name        ::=  (identifier | integer)? ("." attribute_name |
"[" element_index "]")*

Not that it matters, of course.

And the proviso is correct: blanks and integers cannot be mixed in the
same string.

Thanks for looking at this!

Terry, are you still interested in documenting this (please say yes!)?
I'm hoping it can be done by the beta release.

Thanks.
Eric.

Yes, added to 'do in next few days' list.

Terry J. Reedy wrote:
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
> 
> Yes, added to 'do in next few days' list.

Thanks so much.

Suggested doc change for
LibRef / StringServices / string.... / Format String Syntax

1. In the grammar box, replace the field_name line with
"
field_name ::=  arg_name ("." attribute_name | "[" element_index "]")*
arg_name   ::= (identifier | integer)? 
"
The current text ambiguously uses "field_name" for both 'field_name' and
'arg_name'.  I found explaining the rule for blank arg_names in
field_names easier and clearer with two separate unambiguous terms.

Note: 'element_index' should be linked to its definition just as, for
instance, 'attribute_name' is.  Currently it is not.

2. Revise the next two paragraphs as follows (using * to indicate
grammar-term italics as in the current text -- except *all* is just for
emphasis):
"
In less formal terms, the replacement field starts with a *field_name*
that specifies the object whose value is to be formatted and inserted
into the output instead of the replacement field.  The *field_name* is
optionally followed by a *conversion* field, which is preceded by an
exclamation point '!', and a *format_spec*, which is preceded by a colon
':'.  These specify a non-default format for the replacement value.

The *field_name* itself begins with an *arg_name* that is either a
number or a keyword. If it’s a number, it refers to a positional
argument of the str.format() method, and if it’s a keyword it refers to
a named keyword argument. If the numerical arg_names in a format string
are 0, 1, 2, ... in sequence, they can *all* be omitted (not just some)
and the numbers 0, 1, 2, ... will be automatically inserted in order. 
The *arg_name* can be followed by any number of index or attribute
expressions. An expression of the form '.name' selects the named
attribute using getattr(), while an expression of the form '[index]'
does an index lookup using __getitem__().
"
Note: getattr and __getitem__ should be left linked as in the current text.

3. In the following examples, add
'''
"From {} to {}"      # Same as "From {0] to {1}"

Thanks, Terry. Your changes look reasonable to me. Can you commit them,
or at least convert it to a patch against the existing docs?

I am not a committer and cannot make patches.  However, I did download
http://svn.python.org/view/python/trunk/Doc/library/string.rst?revision=70650&view=markup,
as string27.txt, carefully edit using the existing rst format, and
upload.  I trust you can make the patch and commit.

PS. I first edited
http://svn.python.org/view/python/branches/py3k/Doc/library/strings.rst?revision=63803&view=markup
but then noticed that this goes in 2.7.  My impression is that the
procedure is to commit to trunk and then forward port, so I redid it as
indicated above.  But if you are going from 3.1 to 2.7, I will upload
the 3.1 revision.

Thanks, Terry.

I think the only changes I'll make are:

arg_name: (`identifier` | `integer`)*
should be:
arg_name: (`identifier` | `integer`)?

And leave:
conversion: "r" | "s"
instead of:
conversion: "r" | "s" | "a"
because 'a' isn't valid in 2.7.

Documentation changes checked into trunk in r71788 and py3k in r71790.

Issue closed.