[Python-Dev] PEP 292, Simpler String Substitutions
Barry A. Warsaw
barry@zope.com
Wed, 19 Jun 2002 07:23:59 -0400
>>>>> "RH" == Raymond Hettinger <python@rcn.com> writes:
>> 1. $$ is an escape;
>> it is replaced with a single $
RH> Hmm, some strings (at least in the spam I receive) contain
RH> $$$$$$. How about ${$}?
How often will you be interpolating into spam? Sounds like it could
get messy. ;)
>> Handling Missing Keys
>> What should happen when one of the substitution keys is missing
>> from the mapping (or the locals/globals namespace if no
>> argument is given)? There are two possibilities: - We can
>> simply allow the exception (likely a NameError or KeyError) to
>> propagate. - We can return the original substitution
>> placeholder unchanged.
RH> And/Or,
RH> - Leave placeholder unchanged unless default argument
RH> supplied: mystr.sub(mydict, undefined='***') # Fill unknowns
RH> with
RH> stars
RH> And/Or,
RH> - Raise an exception only if specified:
RH> mystr.sub(mydict, undefined=NameError)
RH> And/Or
RH> - Return a count of the number of missed substitutions:
RH> nummisses = mystr.sub(mydict)
I /really/ dislike interfaces that raise an exception or don't, based
on an argument to the function. Returning the number of missed
substitutions doesn't seem useful, but could be done with a regexp.
Filling unknowns with stars could just as easily be done with a
different safedict wrapper.
The specific issue is when using locals+globals. In that case, it's
seems like the problem is clearly a programming bug, so the exception
should be raised.
>> BDFL proto-pronouncement: It should always raise a NameError
>> when the key is missing. There may not be sufficient use case
>> for soft failures in the no-argument version.
RH> I had written a minature mail-merge program and learned that
RH> the NameError approach is a PITA. It makes sense if the
RH> mapping is defined inside the program; however, externally
RH> supplied mappings (like a mergelist) can be expected to have
RH> "holes" and launching exceptions makes it harder to recover
RH> than having a default behavior. The best existing Python
RH> comparison is the str.replace() method which does not bomb-out
RH> when the target string is not found.
I agree that certain use cases make the exception problematic. Think
a program that uses a template entered remotely through the web. That
template could have misspellings in the variable substitutions. In
that case I think you'd like to carry on as best you can, by returning
a string with the bogus placeholders still in the string.
-Barry