2 ms·

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

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++

jsnell 1y ago
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.
- linsomniac 1y ago
  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.
dsego 1y ago
Because JS has it in the form of tagged template literals.
chrisrodrigue 1y ago
We have a handful of ways to create strings now. Meanwhile, pytest is still not part of the standard library.
perlgeek 1y ago
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.
- dec0dedab0de 1y ago
  putting it in the standard library would handle those issues.
Mawr 1y ago
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.
nhumrich 1y ago
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.
- dec0dedab0de 1y ago
  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.
  - dec0dedab0de 1y ago
    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
    - nhumrich 1y ago
      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.
sanderjd 1y ago
Counterpoint: It's good to add well designed and useful features to programming languages.

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++

jsnell 1y ago

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.

linsomniac 1y ago
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.

dsego 1y ago

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

chrisrodrigue 1y ago

We have a handful of ways to create strings now. Meanwhile, pytest is still not part of the standard library.

perlgeek 1y ago

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.

dec0dedab0de 1y ago
putting it in the standard library would handle those issues.

Mawr 1y ago

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.

nhumrich 1y ago

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.

dec0dedab0de 1y ago
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.
- dec0dedab0de 1y ago
  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
  - nhumrich 1y ago
    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.

sanderjd 1y ago

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