4 ms·

The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on". A string literal whose value automatically c

The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on". A string literal whose value automatically changes with the code surrounding it sounds like a really bad idea. I also noticed that the PEP uses str.format method as a strawman, ignoring the fact that % string interpolation is very popular and does not need replacing, which is at the core of this problem in the first place; Someone keeps trying to replace something that does not need replacing. Furthermore, I can't help but think that this would eventually become a complete literal string DSL (if not one already) inside of Python. I hope this PEP does not get accepted.

TazeTSchnitzel 11y ago
> The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on", which is an unsettling thought to have about Python, my favorite language. > The idea of having a string that is automatically dynamic and whose value is hardly predictable upon first glance, wholly dependent on the stability of the code surrounding it, sounds like an absolutely horrendous idea. What?! It's not a dynamic string. It's a string concatenation expression with syntactic sugar. This isn't PHP's register_globals. It's PHP's "{$n + 1}". What this does, you can already do. "Foo " + bar + " baz" already exists. This is merely nicer syntax.
- imakesnowflakes 11y ago
  The difference is, > "Foo " + bar + " baz" is not a string literal, neither is one using format or % function. All of those things return dead strings. This pep is about creating a kind of 'live' string literal, which python does not have right now (or need IMHO). So this is not merely a nicer syntax.
  - svieira 11y ago
    It is not live (unless I am mis-understanding what you mean by live) - it is evaluated once. That is to say: def magic(a, b): return f"{a} and {b}" s = magic(4, 8) print(s) a, b = 3, 7 print(s) prints `4 and 8` in both cases.
    - imakesnowflakes 11y ago
      It is live in the sense that you can take that string literal and put it in a different context and it will result in a different evaluation, possibly yielding different value for the string and possibly different side effects (after calls to evaluate expressions).

TazeTSchnitzel 11y ago

> The first thing I thought of when I looked at the PEP was, "this is like a string version of register_globals=on", which is an unsettling thought to have about Python, my favorite language. > The idea of having a string that is automatically dynamic and whose value is hardly predictable upon first glance, wholly dependent on the stability of the code surrounding it, sounds like an absolutely horrendous idea. What?! It's not a dynamic string. It's a string concatenation expression with syntactic sugar. This isn't PHP's register_globals. It's PHP's "{$n + 1}". What this does, you can already do. "Foo " + bar + " baz" already exists. This is merely nicer syntax.

imakesnowflakes 11y ago
The difference is, > "Foo " + bar + " baz" is not a string literal, neither is one using format or % function. All of those things return dead strings. This pep is about creating a kind of 'live' string literal, which python does not have right now (or need IMHO). So this is not merely a nicer syntax.
- svieira 11y ago
  It is not live (unless I am mis-understanding what you mean by live) - it is evaluated once. That is to say: def magic(a, b): return f"{a} and {b}" s = magic(4, 8) print(s) a, b = 3, 7 print(s) prints `4 and 8` in both cases.
  - imakesnowflakes 11y ago
    It is live in the sense that you can take that string literal and put it in a different context and it will result in a different evaluation, possibly yielding different value for the string and possibly different side effects (after calls to evaluate expressions).