3.x str.format() format strings denote replacement fields with braces{}. Currently, replacement fields *must* contain "either the numericindex of a positional argument, or the name of a keyword argument". [libref / 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 whatwas *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 andthen 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 descriptionand 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-blankspecs would then be an error and raise an exception.This idea was posted today on Python-ideas thread "String formatting andnamed tuple".  So far, +1 from Aahz, Raymond Hettinger, and MathiasPanzenbock.

It's easy enough to implement. Although the 'all-or-nothing' aspect is alittle tough, I'll have to give it some thought.Maybe the best way to do this is to first create a string.Formattersubclass 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 fromprint('{0:9}'.format(33))you make the argument number implicit and remove the colon you'd getprint('{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 tellwhether "{0}" is missing the positional parameter or is missing theformat specifier.

+1 for the general idea from me too, assuming that all the details canbe 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 fromstring.Formatter. It has the following shortcomings, which would all beaddressed 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 completeparser. If anyone really wants them, I could add them. But this is justa proof of concept.Admittedly this isn't a drop-in replacement for ''.format(), but itshould give a taste of what using it would be like.

Unfortunately, `'{d}{s}{f}'.format(3, 'foo', 3.14)` can't work as youexpect it to, because it already means "display the keyword argumentsnamed `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 bepossible.

Answering first questionmsg81873.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 anexclamation 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 requiresunshift-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 darwinType "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 thisimplements what people are expecting.The talk about '{:d}' and the like is just to make sure all the casesare 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-shiftAgreed.

auto_number_formatter_2.py lets you experiment with this with a syntaxmore 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 linux2Type "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 thereplacement 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, andobject access. At this point the improvement of leaving out the indexnumbers is less clear. I'll leave it for debate if this is useful. Ithink it probably is, if only because it's easier to explain thebehavior: If you leave out the 'field name', a sequential number isadded in front of the 'replacement string' (usingPEP 3101 nomenclature).

I'm attaching a patch that delivers the basic functionality instr.format. This patch is against trunk, although it will probably workelsewhere.DO NOT USE THIS PATCH IN ANY SERIOUS WORKIt doesn't implement all of the needed functionality, it probably has amemory 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, butI just haven't had the time to finish it up. I wanted to get this postedso others can play with it and we can reach a decision if we want to addthis functionality. Personally, I think it's a great improvement, andthe more I play with it the more I like it.If we reach a consensus that the feature should be added, I can probablyget 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 darwinType "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 fieldspecification>>>

Also note that this patch causes a few tests to fail, since they'retrying to ensure that '{}'.format will fail. If we go forward I'lladdress 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 fordropping all of my remaining uses of %-formatting at some point in thefuture.

Would someone like to point the python-ideas discussion whichrationalizes this request?And what would be written in the documentation? As much as Iunderstand this, emptry braces {} for replacement fields is kind ofunseen 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 ofthe proposal. After the phrase "either the numericindex of a positional argument, or the name of a keyword argument." inthe docs, add a sentence along the lines of the following:  "If the index/name is left out for all replacement fields, then thesequential values 0, 1, ... will be automatically inserted."

It may also be worth explicitly stating the following in the docs: "Notethat automatically numbered and explcitly namged/numbered replacementfields cannot be mixed in a single format string". (This could probablybe relegated to a footnote).This proposal is also significantly better defined than the ratherbizarre 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 notmanual 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 2braces 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 withoutmodifying the signatures to the public methods, in particularget_field(). The design of string.Format doesn't support state that iscreated in format() or vformat() and is passed in to get_field(). Icould use object state in the string.Format instance, but that doesn'twork well, due to the fact that format() can be called multiple timesper instance lifetime. string.Format really needs to have no state ofits own, for example in the case where a single instance is being usedby multiple threads or if it calls the same instance of itselfrecursively. I'm going to punt on this for now.

Not sure if that's worth it -- doesn't sound like the people who wouldneed 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 yourlater 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 automaticfield 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 fieldspecificationYou 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 justrealized 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 itwould be to disallow them. And I rather like the '{:{fmt}}' example!I suggest leaving them in. They might be useful, and it makes theimplementation 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 mixauto-numbering and manual specification of indexes.As for string.Formatter, I agree we should leave it alone. I'd besurprised if anyone is actually using it, anyway. But I'd love to hearotherwise.

> 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 itwould 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 themoment (for the same reason that __format__() methods are tricky towrite). That said, creating a locale aware version of string formattingbased on string.Formatter is such an obvious idea that I would actuallybe surprised if someone *hasn't* done it by now (they may not havepublished it anywhere, but I expect someone has implemented it for theirown use).That said, I think it's OK for string.Formatter to lag the actualstr.format implementation when it comes to features like this. I see itas similar to the formatting mini-language parser problem: the primarygoal is to have a good implementation and syntax for str.format, whileproviding the tools to allow people to create alternative formatterswith similar power is secondary.

Committed:r70364 (trunk)r70366 (py3k)The docs still need updating. If anyone with more knowledge of thedocumentation system than I have would like to tackle those, please feelfree!

Either Brandl or Peterson can and typically will change the .rst sourceif given the exact new text.  For me to write that, I need to know thegrammar you actually implemented.  Did you, in essence, simply changefield_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 samestring, so that{.attr} and {[dex]} become legal?  Or are those stillillegal because only totally blank field names are allowed, so that thenew field_name rule is essentiallyfield_name        ::=  ((identifier | integer) ("." attribute_name | "["element_index "]")*) | ( )(with the same proviso).The existing doc text after the grammar box is slightly ambiguous orcontradictory in that it first says that field names *are* ints or namesand then says, correctly, that they *begin* with an int or name. (Iwould like to fix this in addition to adding a sentence.) Hence 'blankfield name' can have two slightly different meanings and hence thequestion 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 thesame 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 forLibRef / StringServices / string.... / Format String Syntax1. 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 infield_names easier and clearer with two separate unambiguous terms.Note: 'element_index' should be linked to its definition just as, forinstance, 'attribute_name' is.  Currently it is not.2. Revise the next two paragraphs as follows (using * to indicategrammar-term italics as in the current text -- except *all* is just foremphasis):"In less formal terms, the replacement field starts with a *field_name*that specifies the object whose value is to be formatted and insertedinto the output instead of the replacement field.  The *field_name* isoptionally followed by a *conversion* field, which is preceded by anexclamation 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 anumber or a keyword. If it’s a number, it refers to a positionalargument of the str.format() method, and if it’s a keyword it refers toa named keyword argument. If the numerical arg_names in a format stringare 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 attributeexpressions. An expression of the form '.name' selects the namedattribute 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 downloadhttp://svn.python.org/view/python/trunk/Doc/library/string.rst?revision=70650&view=markup,as string27.txt, carefully edit using the existing rst format, andupload.  I trust you can make the patch and commit.

PS. I first editedhttp://svn.python.org/view/python/branches/py3k/Doc/library/strings.rst?revision=63803&view=markupbut then noticed that this goes in 2.7.  My impression is that theprocedure is to commit to trunk and then forward port, so I redid it asindicated above.  But if you are going from 3.1 to 2.7, I will uploadthe 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 inr71788 and py3k inr71790.Issue closed.