[Python-Dev] *Simpler* string substitutions

Gustavo Niemeyer niemeyer@conectiva.com
Thu, 20 Jun 2002 17:00:25 -0300

> Here is my sense of the "interpolation" problem (based entirely on the
> code I see):
>  * 95% of all scripts (or modules) need to do string interpolation
>  * 5% of all scripts want to be explicit about the types
>  * 10% of all scripts want to submit a dictionary rather than the
> current namespace
>  * 5% of all scripts want to do printf-style formatting tricks
> Which means that if we do the math in a simplistic way, 20%
> modules/scripts need these complicated features but the other 75% pay

I'm curious.. where did you get this from? Have you counted?

I think 99% of the statistics are forged to enforce an opinion. :-)

> Of course the syntax is flexible: you get to choose HOW you pay
> (shifting from positional to name) and thus reduce some costs while you
> incur others, but you can't choose simply NOT to pay, as you can in
> every other scripting language I know. 
> And remember that Python is a language that *encourages* readability.
> But this kind of code is common:
>  * exception.append('\n<br>%s%s&nbsp;=\n%s' % (indent, name, value))
> whereas it could be just:
>  * exception.append('\n<br>${ident}${name}&nbsp;=\n${value}')

That's the usual Perl way of string interpolation. I've used Perl in
some large projects before being a python adept, and I must confess I
don't miss this feature. Maybe it's my C background, but I don't like
to mix code and strings. Think about these real examples, taken
from *one* single module (BaseHTTPServer):

"%s %s %s\r\n" % (self.protocol_version, str(code), message)

"%s - - [%s] %s\n" % (self.address_string(),

"%s, %02d %3s %4d %02d:%02d:%02d GMT" % (self.weekdayname[wd],
					 self.monthname[month], year,
				         hh, mm, ss)

"Serving HTTP on", sa[0], "port", sa[1], "..."

"Bad HTTP/0 .9 request type (%s)" % `command`

"Unsupported method (%s)" % `self.command`

"Bad request syntax (%s)" % `requestline`

"Bad request version (%s)" % `version`

> Which is shorter, uses fewer concepts, and keeps variables close to
> where they are used. We could argue that the programmer here made the

Please, show me that with one of the examples above.

> The tax is small but it is collected on almost every script, almost
> every beginner and almost every programmer almost every day. So it adds
> up.

That seems like an excessive generalization of a personal opinion.

Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]