> 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 =\n%s' % (indent, name, value))
>
> whereas it could be just:
>
> * exception.append('\n<br>${ident}${name} =\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(),
self.log_date_time_string(),
format%args))
"%s, %02d %3s %4d %02d:%02d:%02d GMT" % (self.weekdayname[wd],
day,
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 ]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4