Python’s new t-strings

Why does this need to be a language feature. This could just be a separate library, we could use brackets instead of a letter before a string. I fear, Python is going down the path of C++

It being a language feature gives you controlled access to the lexical scope, such that the template string can refer to variables by name rather than having to pass each value as a parameter. Doing it via parameters is repetitive and/or error-prone.

Because JS has it in the form of tagged template literals.

We have a handful of ways to create strings now.

Meanwhile, pytest is still not part of the standard library.

If it's not a language feature, there's always a risk of fragmentation. Some people won't use it because it adds another dependency, that means fewer programmers will be familiar with it. Others will come up with their own, slightly incompatible implementation. See for example Perl and its various Object Orientation frameworks (Moose, Mouse, Moo, Mo, M, Mojolicious comes with its own...)

Other languages have a policy of prototyping such things out of core, and only adding it to the core language if it gains traction. Of course that works better if the language has a mechanism for extending the syntax out of core.

It's not as simple as "more features" == "closer to C++". Features are not equal to each other in terms of impact on language complexity.

t-strings don't interact with anything else in the language; they, as you yourself pointed out, could almost be an isolated library. That makes them low impact.

This is also true syntactically; they're just another type of string, denoted by "t" instead of "f". That's easy to fit into one's existing model of the language.

Moreover, even semantically, from the point of view of most language users, they are equivalent to f-strings in every way, so there's nothing to learn, really. It's only the library writers who need to learn about them.

Then we have to consider the upsides - the potential to eliminate SQL and HTML injection attacks. The value/cost is so high the feature a no-brainer.

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.

Counterpoint: It's good to add well designed and useful features to programming languages.

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

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__.

putting it in the standard library would handle those issues.

That is exactly what I ended up doing:

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

You CAN get access to the calling scope of a function. Something like:

    current_frame = inspect.currentframe()
    env = current_frame.f_back.f_locals.copy()

I did it in uplaybook so that you can do things like:

    for module in ['foo', 'bar', 'baz']:
        ln(path="/etc/apache2/mods-enabled", src="/etc/apache2/mods-available/{{ module }}.load")

This is an ansible-like tooling with a python instead of YAML syntax, hence the Jinja2 templating.

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.