For R, and others who haven't read the PEP or worked a lot with the web, here are some really strong advantages of the new string formatting over the old.
Note: I'm not saying that you have to use one or the other. I'm just pointing out some of the things that the new format gives us - things which allow the next generation of application simplification (especially web apps). When working on resource-oriented, generalized display applications (eg, most any modern website), you commonly run into the problem of wanting to display a bunch of different things in a bunch of different ways - and on the web, display means "convert to a string for the browser". However, the mapping is not a complete graph. Rather, there are usually some rules. For example: * I want to show the same thing to different people in different ways, depending on permissions. * Sometimes I want to show a thing as a full display, and sometimes as a link to go get more. Usually, the template (context) knows how I want to show something, but the thing knows how to show itself. I can solve this using the new string formatting. In particular, by using the "{0.property}", "{variable[index]}", and similar substitutions (none of which can be done in the old syntax). As a result, I end up with an entire website, of an arbitrary number of pages, being supported with one, 5-line "generate the view" method. There is 0 code per page. Here are some of the simpler examples. First, there might be a link to a user's page: "<a href='{0.url}">{0.display_name}</a>" And a link to a blog entry: "<a href='{0.url}">{0.display_name}</a>" Wait...isn't that the same? Yup. There's the first widget: a link. Any resource that knows its own name and URL (and that's all of them) can be shown as a link. Similar widget extraction hugely reduces the other combinations I have to support - eliminating a lot of redundancy, and many LoC. However, display_name doesn't show up the same for all users. Administrators often get additional data (such as the username), everywhere they see a user's name. Friends of a user see little rollovers that tell them more about that user - such as a photo. Fortunately, I defined my user class like: class User: @property def display_name(self): # viewer-dependent context stuff here. And the new string formatting calls my arbitrary code, without anyone having to think about it. But display_name doesn't need to know how to display a name - it just needs to choose which style to use. I can also extract that out to a template, and then have "<img src='{0.photo.url}' />{0.first}" for friends and "{0.first} {0.last} ({0.username})" for admins, and so on. My display_name code just needs to choose which representation to use - it doesn't define that format. It just returns one of several opaque string constants / widgets, making refactoring trivial. Similarly, I can use "{resource.full_display_for_viewer}" or "{resource.link_display}" to tell the resource how I want it to display itself. Hm. Doesn't that make widget sets (a la ToscaWidgets / TuboGears) and template languages (such as Cheetah / Kid / Mako) a little obsolete? Well, sorta. After all when displaying my user class, I can do this too: "{self.blog_entries.recent.as_ordered_list.using.link_display}". Is that pathological? Probably (unless you have a functional programming background or like domain-specific languages). Looping is, after all, one of the things a real templating system gives you. However, now you don't need to use it for common (and simple) things. Eventually, you do run into stuff for which you want a full templating language. And I use them. For example, they define the base page layouts. The point, however, is that a lot of the lower-level things can be done without using the templating language. And this reduces the number of Mako templates you have lying around, while still allowing great decomposability. Most of these things could be done by having the object override __format__(self). However, that jams my display code in with the rest of my resource class. This way, I can have templates pull out what they want from my resources. And I can compute the template to use and the resources to use it on independently, then just pass it to my displayer method. These are capabilities that %s has no chance to every approach. The ability to use new-style format strings reducees my LoC by a half-ton, and they make what they leave behind a lot easier to read. Being higher-level constructs, they allow me to eliminate redundancy, and that's the real purpose of a programmer. -- http://mail.python.org/mailman/listinfo/python-list