Steven Majewski wrote:

...

particularly whether the syntax was acceptable, or if a 'magic string' solution was still preferred.

IMHO, string interpolation should be one of the easiest things in the language. It should be something you learn in the first half of your first day learning Python. Any extra level of logical indirection seems misplaced to me. Paul Prescod

On Mon, 14 Jan 2002, Paul Prescod wrote:

...

particularly whether the syntax was acceptable, or if a 'magic string' solution was still preferred.

IMHO, string interpolation should be one of the easiest things in the language. It should be something you learn in the first half of your first day learning Python. Any extra level of logical indirection seems misplaced to me.

Do you have any comments or suggestions about a substitution syntax, Paul? I think anything except PEP 216's magic initial u" for strings is able to be done with an object extension rather than a syntax change, including the substitution syntax within the magic string. I kept '%' rather than '$' because I assumed that particular char choice was a rather arbitrary part of the design patterned after Tcl or Perl, and that by keeping '%' I could do it with a dict. If a different syntax is desired, then it can be done by extending string to a magic format string object (rather than a magic string syntax). I'm not sure what you mean by logical indirection here: is that a comment on the syntax, or do you object to the idea of not implementing substitution by a language syntax change. ( But if what you mean is you want fewer chars for a double substition, that's something that can be fixed.) One reason I would prefer a "magic object" implementation, rather than a 'magic syntax' one is that, after playing around with this for a bit, I can see that there are a lot of possibilities for various substitution and template languages. A language syntax change, once accepted is cast in stone (and a new revised proposal is much less likely to be considered) while we can muck about and experiment with object extensions both before and after the get put into the standard lib. -- Steve Majewski

...

+1

Was that +1 for PEP 216?, my alternative proposal? or Paul's comments?

It was a +1 for Paul's comments, both its principles and as maybe a -0.3 criticism of your alternative. No opinion on PEP 215. ## Jason Orendorff http://www.jorendorff.com/

[ Oops. Initial subject line said incorrectly PEP 216] On Mon, 14 Jan 2002, Paul Prescod wrote:

[...] As PEP 215 mentions, this also has advantages for reasoning about security. If I tell a new programmer to avoid the use of "eval" unless they consult with me, I'll have to tell them to avoid EvalDict also. My usual approach is to consider eval and exec to be advanced (and rarely used) features that I don't even teach new programmers.

But if you're going to allow interpolation of the results of arbitrary function into a string, it's going to be a security problem whether or not you use 'eval' to do it. My code hides the eval in the object's python code. u" strings would hide the eval in the C code. How is one more or less secure than the other. The security issue seems to be an argument for a non-language-syntax implementation, as it means that: the hidden eval's could be controlled with a restricted execution environment. ( Also the same advantages I cited to easily experiment with alternatives -- we could roll out a solution without having to tackle the security issue right away.) Also, although I agree with most of your other comments on making it simple and easy, the security issue argues against making it TOO simple. For example, I was considering making the current namespace of the call a default, so you wouldn't need globals() -- but I was worried that because of security and other issues, maybe that was too much "magic" . I think maybe how much magic is enough and how much is too much is one of the issues to discuss. Thanks for expanding on your initial comment. I think you're right that it needs to be simpler. But, for several reasons, security among them, I'm still -1 on PEP 215. -- Steve

Steven Majewski wrote:

....

But if you're going to allow interpolation of the results of arbitrary function into a string, it's going to be a security problem whether or not you use 'eval' to do it. My code hides the eval in the object's python code. u" strings would hide the eval in the C code. How is one more or less secure than the other.

I think you mean $" strings, not u" strings. Given: a = $"foo.bar: $foo.bar(abc, 5)" I can translate that *at compile time* to: a = $"foo.bar: %s" % foo.bar(abc, 5) No runtime evaluation is necessary. So I see no security issues here. On the other hand, evaldict really does have the same semantics as an eval, right? Probably it is no more or less dangerous if you only do a single level of EvalDict-ing. But once you get into multiple levels you could get into a situation where user-provided code is being evaluated. The first level of EvalDict incorporates the user-provided code into the string and the second level evaluates it. Ping's current runtime implementation does use "eval" but you could imagine an alternate implementation that actually parses the relevant parts of the string according to the Python grammar, and merely applies the appropriate semantics. It would use "." to trigger getattr, "()" to trigger apply, "[]" to trigger getitem and so forth. Then there would be no eval and thus way to eval user-provided code. Paul Prescod

On Mon, 14 Jan 2002, Paul Prescod wrote:

Steven Majewski wrote:

...

....

But if you're going to allow interpolation of the results of arbitrary function into a string, it's going to be a security problem whether or not you use 'eval' to do it. My code hides the eval in the object's python code. u" strings would hide the eval in the C code. How is one more or less secure than the other.

I think you mean $" strings, not u" strings. Given:

Oops. Yes.

a = $"foo.bar: $foo.bar(abc, 5)"

I can translate that *at compile time* to:

a = $"foo.bar: %s" % foo.bar(abc, 5)

No runtime evaluation is necessary. So I see no security issues here. On the other hand, evaldict really does have the same semantics as an eval, right? Probably it is no more or less dangerous if you only do a single level of EvalDict-ing. But once you get into multiple levels you could get into a situation where user-provided code is being evaluated. The first level of EvalDict incorporates the user-provided code into the string and the second level evaluates it.

The multiple level was an addition to the last version because that was what some people expressed a desire for in the earlier string interpolation discussion. EvalDict2 does a single level eval. ( Again: that seems to me to be an argument for several alternative object versions rather than one builtin syntax change. )

Ping's current runtime implementation does use "eval" but you could imagine an alternate implementation that actually parses the relevant parts of the string according to the Python grammar, and merely applies the appropriate semantics. It would use "." to trigger getattr, "()" to trigger apply, "[]" to trigger getitem and so forth. Then there would be no eval and thus way to eval user-provided code.

The same things holds for an object implementation. eval isn't required for an implementation. But EVERY implementation of that semantics allows implicit function calls. ( I was going to say 'hidden' function calls, but I'll admit that may be provocative/argumentative.) Your point about compile time optomization holds here: yes, the builtin syntax version allows much of that analysis to be done at compile time, while the object version would need to do all of the analysis on the fly at execution. However, as I noted -- the object implementation would allow customizing a restricted environment ( which is a simple security implementation than code analysis.) And having an explicit argument for the namespace allows more control, as well as reminding you of the magic going on behind the curtains. At least if there's a security problem, you have somewhere to look for holes other than the Python C source code. If I keep an eval based implementation, I probably ought to make a restricted __builtin__ the default. -- Steve

The Jython 2cts. An eval implementation means that for Jython a code using it cannot be run in a Java sand-box context, eval does not work there.

If I keep an eval based implementation, I probably ought to make a restricted __builtin__ the default.

Jython does not support CPython restricted execution. Probably never will. For what it counts I don't care having string interpolation a la Perl in Python. cheers, Samuele Pedroni.

Paul> Sorry I wasn't clear. Let's say it's the second hour of our Paul> Perl/Python class.

Paul> Here's Perl:

Paul> $a = 5; Paul> $b = 6; Paul> print "$a $b";

...

Paul> Here's Python:

Paul> a = 5; Paul> b = 6; Paul> print "%(a)s %(b)s" % vars()

How does Perl handle it if the tokens aren't whitespace separated? Is there an optional enclosing bracket as in shell syntax ? How do you do: "%(word)sly yours" % vocabulary ? (Sorry-- I stopped Perling somewhere around version 4.) -- Steve Majewski

On Mon, 14 Jan 2002, Jason Orendorff wrote:

...

But if you're going to allow interpolation of the results of arbitrary function into a string, it's going to be a security problem whether or not you use 'eval' to do it. My code hides the eval in the object's python code. u" strings would hide the eval in the C code. How is one more or less secure than the other.

There is no security issue with PEP 215.

$"$a and $b make $c" <==> ("%s and %s make %s" % (a, b, c))

These two are completely equivalent under PEP 215, and therefore equally secure.

Your right. I'm confusing PEP 215 with the discussion on PEP 215, where that feature was requested. However, if you allow array and member access as well, which Paul suggests, then you open the security problem back up unless you do some code analysis (as he also suggests) to make sure that [index] or .member doesn't perform a hidden function call ( A virus infected __getitem__ for example. ) -- Steve

On Mon, 14 Jan 2002, Jason Orendorff wrote:

Would someone please explain to me what is seen as a "possible security issue" in PEP 215? Can anyone propose some real-life situation where PEP 215 causes a vulnerability, and the corresponding % syntax doesn't?

Do you mean the current '%' or my expanded example ? Any expanded version -- mine or PEP 215 introduces possible security holes. ( And I'm not even sure that the current "%" doesn't have a hole if it's used "the wrong way" ) But, as Paul said, it depends on the implementation. I said in an earlied post that I confused PEP 215 with the discussion of PEP 215, where some expanded capabilities were suggested. However, on looking at it again closer, I would say that the examples in PEP 215 contradict the Security Considerations paragraph. It has expressions in it that can't be evaluated at compile time, and any list index or member reference can, in Python, invoke a hidden function call. Any implementation is going to require some run time checks. But just in case I'm seeing it all wrong: could you explain to me how PEP 215 *doesn't* have the potential of introducing a security hole ? If the current proof-of-concept implementation does use eval (as Paul stated), then there is (I believe) a security problem with that implementation. Paul has proposed some other implementation tricks, but I'm, not convinced that you can get the same semantics suggested in PEP 215's examples without requiring runtime checks. Since eval is a know security hole, I think the burden of proof is on the proponents. ( And I'm not even demanding proof -- just a convincing argument without too much hand waving and we-have-ways-of-dealing-with-that! ) -- Steve Majewski

Steven Majewski wrote:

...

Your right. I'm confusing PEP 215 with the discussion on PEP 215, where that feature was requested.

However, if you allow array and member access as well, which Paul suggests, then you open the security problem back up unless you do some code analysis (as he also suggests) to make sure that [index] or .member doesn't perform a hidden function call ( A virus infected __getitem__ for example. )

If you have a virus-infected __getitem__ you are screwed regardless. We can't defend against that. The whole point is that we are never evaluating code provided by the user. "Safe" programmer-supplied literal strings are differentated at compile time from arbitrary strings. The interpolation engine only works on safe strings. Calling an overriden __getitem__ or .member is as safe as if they had done it in the way they would today: "%s" % foo.bar() Think of it as pure, compile-time syntactic sugar. If you want it to act like eval, I guess you would do this: $"$(eval('....'))...." which would compile to: "%s" % eval('....') Paul Prescod

Steven Majewski wrote:

On Mon, 14 Jan 2002, Jason Orendorff wrote:

...

Would someone please explain to me what is seen as a "possible security issue" in PEP 215? Can anyone propose some real-life situation where PEP 215 causes a vulnerability, and the corresponding % syntax doesn't?

Do you mean the current '%' or my expanded example ?

I mean the current %. Well? ## Jason Orendorff http://www.jorendorff.com/

Skip Montanaro wrote:

...

So? There are some things Perl does better than Python, some things Python does better than Perl.

It doesn't have anything to do with competing with Perl. It is just about learning from things that other languages do better (in this case simpler) than Python. This feature came from the Bourne shell and is also present in DOS batch, TCL, Ruby, PHP. Python's "%" is much better than nothing (which is what Javascript has) but it is still a pain. First you use it with positional arguments and then realize that is getting confusing so you switch to dictionary arguments and then that gets unweildy because you're just declaring new names for existing variables so you use vars(). But then you want to interpolate the result of a function call or expression. So you have to set up a one-time-use variable. PEP 215 (which I did not write!) unifies all of the use cases into one syntax that can be taught in ten minutes. The % syntax is fine for totally different use cases: printf-style formatting and interpolation of strings that might be generated at runtime. Paul Prescod

Neil Schemenauer wrote:

Jason Orendorff wrote:

...

The substitution only happens once.

My example was not well thought out. I was thinking something more like:

secret_key = "spam" user = "joe" x = "$user said: " + raw_input() print $x

That wouldn't work either since $ only evaluates literals. Amazing what you learn by actually reading the PEP. Yes, I'm an idiot.

Sorry, I haven't followed this thread real closely, but I thought someone said eval() was used under the covers. If x is eval'ed and the string is as above, I get the following in 2.1: >>> secret_key = 'spam' >>> x = raw_input('? ') ? eval("secret_key") # Is the following commented print equivalent the the line below it? ### print "You entered $x" >>> print "You entered", eval(x) You entered spam >>> print "You entered %(x)s" % locals() You entered eval("secret_key") Not sure if that's the same as what you are talking about though. Neal

Steven Majewski wrote:

...

But Jason just said that function calls are not allowed. ( We -- actually, he listed what was allowed, and function calls were definitely not among them. )

I misread Jason's list at first myself. Jason was describing the *output* of the transformation. He said that the output of the transformation would be no more and no less than directly typed code with a) whatever code the programmer explicitly typed in the $-string; b) str() or unicode(); and "$" has the power to eval, but only to eval a literal. As described here (a string prefix rather than an operator c) the + operator applied to strings. "a)" embodies a whole host of things listed in the PEP: "A Python identifier optionally followed by any number of trailers, where a trailer consists of: - a dot and an identifier, - an expression enclosed in square brackets, or - an argument list enclosed in parentheses (This is exactly the pattern expressed in the Python grammar by "NAME trailer*", using the definitions in Grammar/Grammar.)" The PEP also has examples:

...

...

print $'References to $a: $sys.getrefcount(a)' References to 5: 15

PEP 215's examples don't agree with the limitations in it's security section,

To summarize the security section, it says: *All of the text that is ever processed by this mechanism is textually present in the Python program at compile time*. In other words, users of the program can never submit information and have it be evaluated by this mechanism. Paul Prescod

Steven Majewski wrote:

On Mon, 14 Jan 2002, Jason Orendorff wrote:

...

...

But just in case I'm seeing it all wrong: could you explain to me how PEP 215 *doesn't* have the potential of introducing a security hole ?

Gladly.

Every $-string can be converted to equivalent code that uses only:

a) whatever code the programmer explicitly typed in the $-string; b) str() or unicode(); and c) the + operator applied to strings.

But the examples in PEP 215 don't follow those restrictions.

I dunno, it looks like they do to me. $'a = $a, b = $b' ---> ('a = ' + str(a) + ', b = ' + str(b)) $u'uni${a}ode' ---> (u'uni' + unicode(a) + u'ode') $'\$a' ---> ('\\' + str(a)) $r'\$a' ---> ('\\' + str(a)) $'$$$a.$b' ---> ('$' + str(a) + '.' + str(b)) $'a + b = ${a + b}' ---> ('a + b = ' + str(a + b)) $'References to $a: $sys.getrefcount(a)' ---> ('References to ' + str(a) + ': ' + str(sys.getrefcount(a))) $"sys = $sys, sys = $sys.modules['sys']" ---> ('sys = ' + str(sys) + ', sys = ' + str(sys.modules['sys'])) $'BDFL = $sys.copyright.split()[4].upper()' ---> ('BDFL = ' + str(sys.copyright.split()[4].upper())) In every case, the equivalent uses a) some bits of code that the programmer explicitly typed in the $-string; b) str() or unicode(); c) and the + operator (to join the resulting strings). I guess you're thinking "but those bits of code are invoking other functions that aren't in your list". My point is, the equivalent print statement, or % expression (the existing %, not your proposed %) does the exact same thing. print $'here we go: $y maps to $x[y]' print 'here we go: %s maps to %s' % (y, x[y]) print 'here we go:', y, 'maps to', x[y] print 'here we go: ' + str(y) + ' maps to ' + str(x[y]) Is one of these less secure than the others somehow? There is no new security hole here. ## Jason Orendorff http://www.jorendorff.com/

Paul> But then you want to interpolate the result of a function call or Paul> expression. So you have to set up a one-time-use variable. As has been demonstrated, there are several ways to tackle this problem. I first saw something headed in this direction with Zope's (actually DocumentTemplate's) MultiMapping class several years ago. It only aimed to make it easy to interpolate named parameters from several dictionaries simultaneously. Steve Majewski and others have shown how you can do this with an EvalDict type of class, so it's not like you can't do this today. The point is for something to be really worth modifying the syntax of the language I think it has to demonstrate that it's significantly better than the alternatives. The security argument is a red herring. There are enough other ways programmers can blow their feet off. If someone is naive enough to execute the moral equivalent of print raw_input() % EvalDict3() in their programs they will probably learn fairly quickly that it's a questionable programming practice. Paul> PEP 215 (which I did not write!) unifies all of the use cases into Paul> one syntax that can be taught in ten minutes. It unifies all the use cases into *two* syntaxes. The preexisting %-formatted strings aren't going away anytime soon. They are suitable for most applications, so new users would have to contend with at least being able to read, if not write, both forms of string interpolation for the forseeable future if PEP 215 is adopted. It hasn't been demonstrated to me that Steve's EvalDict or something similar couldn't be taught in a similar amount of time. It has the added advantage that it's essentially the same syntax as the current % syntax. You can use expressions where before you had to restrict yourself to names. It requires no change to the language. Just drop it into a module in the std library and away you go. In fact, coded properly (which Steve is eminently capable of doing) it would be 100% backward compatible. People running essentially any version of Python could use it. (I believe Pythonware still makes a 1.4 installer available for Windows.) Paul> The % syntax is fine for totally different use cases: printf-style Paul> formatting and interpolation of strings that might be generated at Paul> runtime. What do you mean by "totally different"? Most examples I've seen so far have looked pretty much like print $"$a $b" which probably covers about 90% of common usage anyway. The examples in PEP-215 don't look any more different than an EvalDict-like class could comfortably handle today either. -- Skip Montanaro (skip@pobox.com - http://www.mojam.com/)

On Mon, 14 Jan 2002, Skip Montanaro wrote:

$'BDFL = $sys.copyright.split()[4].upper()' ---> ('BDFL = ' + str(sys.copyright.split()[4].upper()))

How to you know when to stop gobbling after seeing a dollar sign in the string?

Parse using the "NAME trailer*" production in Grammar/Grammar. -- ?!ng

Steve Majewski wrote:

But Jason just said that function calls are not allowed. ( We -- actually, he listed what was allowed, and function calls were definitely not among them. ) [...]

Well, when the $-string explicitly contains the name of the function to be called, then that falls into category (a). I wrote:

a) whatever code the programmer explicitly typed in the $-string;

I hope this makes things clearer and not worse. :-) ## Jason Orendorff http://www.jorendorff.com/

Steven Majewski wrote:

On Mon, 14 Jan 2002, Jason Orendorff wrote:

...

Steven Majewski wrote:

...

On Mon, 14 Jan 2002, Jason Orendorff wrote:

...

Would someone please explain to me what is seen as a "possible security issue" in PEP 215? Can anyone propose some real-life situation where PEP 215 causes a vulnerability, and the corresponding % syntax doesn't?

Do you mean the current '%' or my expanded example ?

I mean the current %.

Well?

Paul is the one who (rightly) brought up the issue of security with respect to double evaluated strings. But in addition, he seemed to be saying that you can do more with a compile time test than you can with a runtime test. I disagree with that.

I think, for the same semantics, you get the same security issues. I think it's very similar to the compile time type checking vs. dynamic typing problem. (In fact, I think it reduces to the same problem.)

There are clearly some advantages to doing things compile time, but you don't get more security without more restriction.

As long as this "security issue" thread dies, I'm happy. ## Jason Orendorff http://www.jorendorff.com/

On Mon, 14 Jan 2002, Ka-Ping Yee wrote:

The '$' prefix only applies to literals, and cannot be used as an operator in front of other expressions or variables. This issue is pointed out specifically in the PEP:

I think the term "the '$' prefix" was one of the sources of my confusion, as '$' is both a string prefix and a symbol prefix within the string. I think I read "the '$' prefix" as referreing to the second kind where you meant the first. The same goes for discussion of '$' as an operator. (This misreading was the source of the inconsistency I thought I saw between the examples and other statements.)

Therefore, this transformation executes *only* code that was literally present in the original program. (An example of this transformation is given at the end of PEP 215 in the "Implementation" section.)

O.K. Jason's explaination finally got thru to me: it's more clear if I think of it as a preprocessor that really doesn't add any capabilities to the language. I should think of it more like the 'r' string prefix, which is just a syntactic convenience, rather than like the 'u' string prefix, which creates a special kind of (unicode) string. ( Well, it *does* create a special kind of string in the runtime, but you can't access that string to to do anything strange in Python, because as soon as it's assigned, it gets transformed into a 'normal string' . Thinking of it as a preprocessor makes that more obvious.)

(By the way, i myself am not yet fully convinced that a string interpolation feature is something that Python desperately needs. I do see some considerable potential for good, and so the purpose of PEP 215 was to put a concrete and plausible proposal on the table for discussion. Given that proposal, which i believe to be about as good as one could reasonably expect, we can hope to save ourselves the expense of re-arguing the same issues repeatedly, and make an informed decision about whether to add the feature.

Among the possible drawbacks/complaints i see are: more work for automated source code tools, tougher editor syntax highlighting, too many messy string prefix characters, and the addition of yet one more Python feature to teach and document. Security, however, is not among them.)

I'm not wild about more string prefixes, but we've already started down that road, so I can't complain too much. But, as you've already noted: it doesn't add any new capability, just new syntax. ( But it probably as justifiable as the raw string syntax. ) Although I've knocked the idea in the past, I'ld almost rather see some sort of 'macro' facility for python, than to see a bunch of special case syntax added to the language for every feature. -- Steve

On Mon, 14 Jan 2002, Paul Prescod wrote:

Sure, for the same semantics. But EvalDict doesn't have the same semantics. Even if we ignore double interpolation there is the issue of code like this:

...

...

...

def double(): ... user_val = raw_input("Please enter a number:") ... print "%(2*user_val)" % EvalDict

...

...

...

double() Please enter a number: 3 + (os.system("rm -rm *"))

But in EvalDict you have to explicitly pass it a namespace dict. You just don't pass it one with access to os.system ( or most other os calls. ) That's why I disliked an implicit namespace. But your example suggests to me:

...

...

input('?: ') ?: r'raw string' 'raw string'

...

...

input('?: ') ?: u'unicode string' u'unicode string'

...

...

input('?: ') ?: $'$os.system("rm -rm *" )'

I guess you need to special case that out of the compiler also. ( Are there any others lurking about ? ) -- Steve

...

...

...

...

"SM" == Steven Majewski writes:

SM> Since PEP 216 on string interpolation is still active, I'ld SM> appreciate it if some of it's supporters would comment on my SM> revised alternative solution (posted on comp.lang.python and SM> at google thru): [Steve's EvalDict] For completeness, here's a simplified version of Mailman's _() function which does auto-interpolation from locals and globals of the calling context. This version works in Python 2.1 or beyond and has the i18n translation stuff stripped out. For the full deal, see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/mailman/mailman/Mailman/i18n.py?rev=2.4&content-type=text/plain Cheers, -Barry -------------------- snip snip --------------------dollar.py import sys from UserDict import UserDict from types import StringType class SafeDict(UserDict): """Dictionary which returns a default value for unknown keys.""" def __getitem__(self, key): try: return self.data[key] except KeyError: if isinstance(key, StringType): return '%('+key+')s' else: return '' % `key` def _(s): frame = sys._getframe(1) d = SafeDict(frame.f_globals.copy()) d.update(frame.f_locals) return s % d BIRD = 'parrot' def examples(thing): bird = 'dead ' + BIRD print _('It used to be a %(BIRD)s') print _('But now it is a %(bird)s') print _('%(BIRD)s or %(bird)s?') print _('You are not %(morg)s, you are not %(imorg)s') print _('%(thing)s, %(thing)s, what is %(thing)s?') examples(sys.argv[1]) -------------------- snip snip -------------------- % python /tmp/dollar.py brain It used to be a parrot But now it is a dead parrot parrot or dead parrot? You are not %(morg)s, you are not %(imorg)s brain, brain, what is brain?

But your example suggests to me:

...

...

...

input('?: ') ?: $'$os.system("rm -rm *" )'

I guess you need to special case that out of the compiler also. ( Are there any others lurking about ? )

The user could just as well type ?: os.system("rm -rf *") and save some keystrokes. input() is totally insecure. Always has been. Nothing new here. ## Jason Orendorff http://www.jorendorff.com/

...

...

...

...

"jepler" == writes:

jepler> Well, I guess we could add _ and $_ strings to Python, jepler> right? Ug. t'' strings have been discussed before w.r.t. i18n markup, but I don't like it. I think it's a mistake to proliferate string prefixes. But search the i18n-sig for more discussion on the topic. -Barry

On Wed, Jan 16, 2002 at 08:17:54AM -0500, Barry A. Warsaw wrote:

Ug. t'' strings have been discussed before w.r.t. i18n markup, but I don't like it.

...

...

...

...

"JE" == Jeff Epler writes:

JE> ... and you like $'' strings? No! :) JE> That suggestion was intended to bring a bad taste to JE> *everybody*'s mouth, as much as t'' alone does to yours. Ah, no wonder I've had to drink 3 sodas today. I wondered what that foul flavor was, especially since I made sure to brush my teeth this morning! JE> (Hmm, and then I might need a raw unicode interpolated JE> translated string ... is that spelled $_ur'' or r_$u'' ?) Exactly why I'm against adding more string prefixes. Remember that the _ thingie we currently recommend for gettext /isn't/ prefix proliferation. E.g.: _(u'translate this') _(ru'and this') It's just a function call with a convenient name (and even that's just a convention, of course). -Barry