[Python-3000] features i'd like [Python 3000?] ... #4: interpolated strings ala perl

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 4, 2006, at 5:08 AM, Ben Wing wrote:

> i see in PEP 3101 that there's some work going on to fix up the string
> formatting capabilities of python.  it looks good to me but it still
> doesn't really address the lack of a simple interpolated string
> mechanism, as in perl or ruby.
[...]
>
> maybe_errout("{title}, line {lineno}: {errstr}\n".format(
>                      title=title, lineno=lineno, errstr=errstr))

I don't have time atm, to go into a lot of detail, but I'll say that  
this latter is exactly what motivated me to add this functionality in  
Mailman, hooking into the _() function for translation string marking.

It's actually a fairly simple thing to implement once you have  
sys._getframe() (can you guess what motivated me to add that  
too? :).  The implementation in Mailman 2.1 still uses %-strings by  
default, but Mailman 2.2 will use PEP 292 $-strings by default.   
Given an implementation of PEP 3101, you could easily make the  
interpolation use that instead.

After several years of use, I'm strongly +1 for this feature in some  
form or another.  Whether it needs to be part of the language or can  
be provided in a library module, I'm not so sure about.  Certainly  
for Mailman it works fine as a library module because any string  
that's going to have this interpolation feature is going to be  
translatable and thus hookable with uber-_().  I tend to think that  
with the switch to functional print, you'd have a convenient place to  
hook into with a library somehow.

There should be little security concern about feature specifically,  
but you do need to be aware of an issue once you start hooking into  
catalogs.  It's possible that a nefarious or sloppy translator could  
expose internal variables if the translated string used an "unsafe"  
local instead of the "safe" variety.  For example, it's often the  
case that in a web app you'll have one variable which is a user input  
string from a form, and then another variable which is just the  
escaped version of the same string.  You'll use the latter in your  
translatable string to avoid XSS and the like, but the unsafe version  
is still of course available as a local.  If the translation used the  
wrong one, you'd have an XSS vector (but only in the affected language).

It might also be handy to allow {name.attr} access in the  
interpolated string.  I know it has been for me occasionally.

Anyway, all the parts exist to do this, so I think it's just a matter  
of deciding whether this should be a language feature or library  
feature.  I tend to think the latter is more appropriate given where  
Py3k is already headed.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRXQgd3EjvBPtnXfVAQKSaQP/fD1bdfLRnxxeXxAYal6QbLH1nn7fJRtK
wr55zVw8NyQ2qVeIMF3agd+jsWAPWy1TTj0eR9JBR8N7tbjXY2zauQIpjDlUBXpK
8XucaxYysmjcvz2DhPUUCGHfLzv5Sh9T6oCCno/ja4WcWwCN960wQpgIETIBS2pe
56GHa92876E=
=dQB8
-----END PGP SIGNATURE-----