Hacker News Reader

Comment by nhumrich | Hacker News Reader

This feature actually can't be a library. It needs to be able to preserve the string before the variables are passed in, which a library would be unable to do because f-strings immediately replace all the values. The whole premise of t-strings is to know which values where "hard coded" and which ones are variables. A library can't possibly know that. And a function call wouldn't have access to the local variables. The only way to do this without language support is to pass `locals()` into every function call.

View on HN

Now you have me wondering how difficult it would be to have a class that takes a string and parses through globals to find the context it was called from. maybe causing an exception and abusing a traceback? or maybe we just find our own objectid.... gahh I have to try it now, but I'm setting a timer.

It was easier than I thought, but also took longer than I wanted to. turns out the inspect module provides what you need to pull it off.

This dummy example splits a string that it was given, then if one of those values is in the callers context it saves those in self.context, and has an output function to assemble it all together. Obviously this example is not very useful, but it shows how a library could do this as a class or function without the user having to pass in locals().

  import inspect
  class MyXString:
      """ will split on whitespace and replace any string that is a variable name 
    with the result of str(variable)"""
        def __init__(self, string):
            self.string = string
            caller_locals = inspect.currentframe().f_back.f_locals
            self.context = {}
            for key in  set(string.split()):
                if key in caller_locals:
                    self.context[key] = caller_locals[key]
  
        def output(self):
            output = self.string
            for k,v in self.context.items():
                output = output.replace(k,str(v))
            return output

This looks like a performance nightmare, and would likely never have IDE integration. So I guess I was wrong. It could be a library. But will be much better supported officially.

You don't have to go through all the globals, you just have to get the caller's namespace, which is fairly simple. See e.g. https://stackoverflow.com/a/6618825/27426

For this reason, I think it's not true that this absolutely had to be a language feature rather than a library. A template class written in pure Python could have done the same lookup in its __init__.

That is exactly what I ended up doing:

https://news.ycombinator.com/item?id=43752889

Reply on news.ycombinator.com