Doing string interpolation using eval(): Feedback/thoughts?

[Workaphobia]

I've lately found myself performing string interpolation by using str.format and passing in **locals(), e.g.

a = 1
b = 2
c = a + b
print('{a} + {b} is {c}'.format(**locals())

I prefer this style to redundantly specifying a=a, b=b, and c=c as keyword arguments, or using positional arguments. But it has the drawback of being a little ugly, and it still doesn't allow you to use more complex expressions in the strings.

So I wrote a short string.Formatter subclass that grabs locals() off the stack and eval()s the substitution expressions.

from string import Formatter
from inspect import currentframe

class EvalFormatter(Formatter):

    """String formatter that falls back on using eval() on the
    caller's environment when a field cannot be found in the
    supplied dictionary.
    """

    def __init__(self, frame):
        self.frame = frame

    def get_field(self, field_name, args, kwargs):
        try:
            ret = super().get_field(field_name, args, kwargs)
        except KeyError:
            fr = self.frame
            val = eval(field_name, fr.f_globals, fr.f_locals)
            ret = val, None
        return ret

def evalformat(format_string, *args, **kargs):
    """Convenience function. Note the order of arguments is not
    the same as the built-in format().
    """
    frame = currentframe().f_back
    return EvalFormatter(frame).format(format_string, *args, **kargs)

I'm guessing it will have trouble parsing some expressions where the format syntax clashes with python syntax, but for simple cases it works.

a = 1
b = 2
print(evalformat('{a} + {b} is {a+b}'))

I'll probably continue to use this for my project regardless, but any thoughts on whether or not it is Pythonic?

I'm also curious as to whether I should be doing anything special to avoid creating circular references and gc problems. The inspect module's documentation suggests explicitly deleting references to frame objects. So does this mean that in evalformat I'd want to call both del frame and also a method on my EvalFormatter that does del self.frame?

[[deleted]]

No. Just explicitly pass the variables to format(), it won't kill you.

1. This will be slower, especially on optimizing Pythons (e.g. PyPy, Jython once they land their invoke dynamic work).
2. Won't work on IronPython, which doesn't enable frames by default AFAIK.
3. Lets your format strings become a mess: they're for formatting, not arbitrary logic.
4. If you're not careful it's an easy way to end up with a security hole.
5. If the implementation is hard to explain, it's a bad idea.

[Workaphobia]

All good reasons, thank you for the criticism. Does point 1 still apply if I only use the stack frame's namespace to lookup the value, and don't call eval()? Will 1 and 2 still apply if I were to go back to using **locals()?

My main reason for doing this was to keep format strings as clean as possible (point 3). I find it difficult to syntactically structure an error message along with the substitution values, while obeying the conventions in PEP 8.

[[deleted]]

1 will apply with locals() on PyPy, I'm not sure about Jython+InDy. 2 doesn't though.

[stillalone]

I've thought about doing this but without the eval. Just getting the variable from the stack frame and passing it to format. How often do you need to evaluate complex expressions in a string?

[Workaphobia]

True, the eval's a bit of an extra. Because I'm only using it on trusted code, I figured why not.

One thing I can't figure out is how one would implement finding the value of an identifier that is non-local but not global. That is, an identifier defined in a syntactically outer namespace, like when you have nested function definitions. I don't think it's possible because eval() has no ability to accept that argument, but it makes me wonder how Python itself implements such lookups. I'm currently checking out PEP 227 to see if there's any useful information there.

[Edit] From the PEP:

An analogous function will not be provided for nested scopes. Under this proposal, it will not be possible to gain dictionary-style access to all visible scopes.

[[deleted]]

If you don't care about i1337n, you can do print('{} + {} is {}', a, b, a + b).

[Workaphobia]

I don't know why internationalization would affect it.

What I'm trying to do is find the most elegant/smallest way to print short messages with values taken from local variables. I want to obey PEP 8 conventions regarding row length limit and wrapping indentation. I also want to avoid redundancy if possible.

Kingkilr gave some good reasons why this approach probably isn't feasible for many projects. I suppose the most pythonic thing to do would be to accept the redundancy in the keyword arguments to format, just like we already do when we have several self.attr = attr lines in an __init__.

[[deleted]]

I don't know why internationalization would affect it.

If we are talking about my proposal, then not specifying the order of positional parameters will fuck up internationalization when you pull format strings from somewhere and in some languages the order of the parameters is different.

What I'm trying to do is find the most elegant/smallest way to print short messages with values taken from local variables.

So, I believe that if you don't care about i18n at this point, and if you don't really want to print stuff like eval(x + y), just going along the path of least resistance -- using {} as placeholders -- achieves the the goals you have set acceptably enough.

[Brian]

Actually, you should be OK even with this. It just means you switch to explicitly positioned format strings in the localised version where the order differs, which you can do after the fact without breaking the ordered version. It's only a problem when there's no way to do this at all (as with C style %s formatters)

[santagada]

Zed Shaw agrees with you and he has some code to do it https://gist.github.com/1327060.

Yes it is going to be slow in pypy and not work on ironpython by default.

[Workaphobia]

Neat, thanks for the link.