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:
"{0.display_name}"
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 "{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
