[Python-Dev] Re: Yet another string formatting proposal

Oren Tirosh oren-py-d@hishome.net
Sat, 23 Nov 2002 02:46:59 -0500

On Fri, Nov 22, 2002 at 01:49:05PM -0500, Chermside, Michael wrote:
> > The rationale behind the name wasn't just "cuteness". The effect
> > of this method is the exact opposite of the "raw" prefix so the
> > name "cook" was the most natural and descriptive choice.
> But I don't think that it IS the opposite of the "raw" prefix. In
> But in a case where OTHER escapes are used, it wouldn't be:
> You could "fix" this by ALSO processing \ escapes in the cook()
> method, but that confuses two very different processes and would
> only make the feature MORE difficult to use.

In case it wasn't clear from my posting this is exactly what I propose.
Otherwise how would you convert the following run-time embedding to a
compile-time template?

u"Resistance = \{resistance} \N{GREEK CAPITAL LETTER OMEGA}\n"

If cooking did not process ALL escape sequences you would not be able
to just change the 'u' prefix to 'ur' and cook it later.

I don't think it makes it more difficult to use. NOT processing escapes
would be inconsistent and make it difficult to use.