[Raymond Hettinger]
> I'm surprised that we're introducing a new API into the standard library
> and no one is showing the slightest interest in prior art. Cheetah is
> well thought out, fast, and mature (it's been through several evolutions
> in the wild). Also, the Cheetah designers started out by studying the
> existing art from ASP, JSP, PHP, PSP, and such. Templating and string
> substituion is not a new, yet the discussion here has the flavor of
> being thought up from scratch.
The current discussion is also just the latest in years of discussion.
I've had 25 years of using string-interpolation gimmicks in countless
contexts myself, and my preference is a reaction against the practical
problems I had with "too much magic" in them (e.g., I can't remember
the difference between {} vs (), so I know I'll make typos related to
that; I also know I'll have no trouble remembering "if you want $, say
$$", and despite that I'll rarely want $).
...
> FWIW, I'm fine with that. It was a minor suggestion. Either way works.
The question is which works better. Let's make Guido decide <wink>.
> My thought was that simpler string substitutions were going to be
> exposed to the end-user (non-programmers) and that they should not be
> harassed unnecessarily. However, these are easy errors to trap and
> report back to the user -- the only question being how to assign a line
> number to the exception (if I have a ten page user supplied template
> with an error, it would be great to tell them where it is).
Indeed! match_object.string
contains the original template string, and
match_object.start(4)
gives the index at which the unsubstitutable $ appeared. A
string-relative line number can be computed from that, and/or
surrounding context can be inserted in the exception detail.
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