5 ms·

Reddit discussion https://www.reddit.com/r/Python/comments/3gfaji/pep_501_translation_ready_string_interpolation/ https://www.reddit.com/r/Python/comments/3gfa

Reddit discussion https://www.reddit.com/r/Python/comments/3gfaji/pep_501_translation_ready_string_interpolation/ https://www.reddit.com/r/Python/comments/3gfaji/pep_501_tran... I think this and pep 498 are a pretty horrible proposals and does not fit well with the rest of the language and it's spirit. 1. Decrements readability. When variables are hidden inside strings, you need to check for presence of a variable in two contexts. In the code and inside the strings. With format and % functions, you will be able to spot the variable in the argument list, which is part of the code itself. 2. Security concerns regarding automatic evaluation of expressions inside the strings. Also, why was format and % made in such a way as to require an explicit list of variables? What was the reasoning behind it? Is that reason no longer relevant?

masida 11y ago
I agree. For me the automatic "pulling" of local variables from the context feels like "magic", and I think that's an undesirable property for a programming language. Of course, PEP498 has the same issue.
- kerkeslager 11y ago
  > For me the automatic "pulling" of local variables from the context feels like "magic", and I think that's an undesirable property for a programming language. Sounds like "Explicit is better than implicit" from the Tao of Python.
czinck 11y ago
That string interpolation was one of my least favorite things about Perl. We tended to have "$"s in strings just because of the usecase, and I was so afraid of that accidentally being interpolated that I never used double quotes, and instead used single quotes. Single quotes in Perl don't interpolate \n, so this "feature" made me write more code rather than less.
nokcha 11y ago
>With format and % functions, you will be able to spot the variable in the argument list, which is part of the code itself. That is not always true, e.g.: >>> x = 2 >>> print("x = {x}".format(**vars())) x = 2
noobermin 11y ago
For 1, it might be a matter of taste/familiarity. For me, interpolation in Julia makes string formatting easier to understand, at least for short strings. The issue is Julia's interpolation (I hope to god to be wrong about this, if it's wrong, someone correct me) doesn't have format specifiers, which put me in a pickle a few days ago. For 2, can you expand upon this? Not a challenge, but I'm not able to imagine how this would be a security concern, and this might be a failure of my understanding here.
- imakesnowflakes 11y ago
  >can you expand upon this.. It is more of a matter of breaking a general principle, which is don't mix executable stuff (expressions) with non-executable stuff (strings) implicitly. This has been a frequent cause of various security issues in the past eg: Sql injection, xss, various remote code execution vulnerabilities. Strings should be dumb and without any ambiguity. On top of breaking this general principle of not mixing data and code, this pep also want to introduce numerous rules regarding various edge cases, which further makes it harder to reason about it, which increases the chances of slipping a vulnerability. For example, right now, you see a long string, you only need to look at the argument list to see what possible things it can do. Because the string itself is dumb, it cannot lie, and whatever execution that is required to produce that string, happens in the context of code itself. With this pep, this changes. Now a string is not dumb. It is smart. It can do 'stuff' on its own. It can 'hide' things, it can lie and masquerade as something innocent. I think this is bad. Take an example of PHP. You can embedd php code in what ever content. In fact you can embedd php code in a valid image file in the metadata fields, and pass it as an Image. if you can call the image file as a script, then the embedded php code will execute to do your bidding. This has to be one of the most commonly used technique to hack sites running php. Here is one from last day [1]. Those are some of my reasons for the concerns..I know I am not still giving anything specific. But if we could easily think specific cases about how something could be exploited, we wouldn't be implementing that in the first place. So sometimes we must rely on general principles learned from the past while assessing the issues associated with something. Hence my concerns. [1] https://www.reddit.com/r/PHP/comments/3gq3mh/my_site_was_hacked_php_injection_can_anybody/ https://www.reddit.com/r/PHP/comments/3gq3mh/my_site_was_hac...
yoha 11y ago
Another point from the discussion was that there are already three ways to do string formatting in Python: 1. `"Value: %i" % value` 2. `"Value: {}".format(value)` 3. `string.Template('Value: $value').substitute(value=value)` However, the Zen of Python (https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ or run `import this` in a Python interpreter) says "There should be one-- and preferably only one --obvious way to do it.".
dragonwriter 11y ago
> 2. Security concerns regarding automatic evaluation of expressions inside the strings. How are there security concerns? Its a kind of string literal that is expanded into a calls to builtin formatting functions at compile time, so there is no more security concern with evaluating expressions in it then there is with evaluating expressions in the non-string parts of your code. > Also, why was format and % made in such a way as to require an explicit list of variables? What was the reasoning behind it? Is that reason no longer relevant? You can use those without an explicit list of variables, its optional to use explicit variables for clarity (though in many cases the natural naming will also make it redundant in simple cases.)
- imakesnowflakes 11y ago
  >How are there security concerns? It is more about breaking a general principle of not mixing executable stuff and non-executable stuff. I have written more about it here. https://news.ycombinator.com/item?id=10063637 https://news.ycombinator.com/item?id=10063637 >its optional to use explicit variables for clarity I don't think it is optional. If it was optional, then the behavior would be to interpolate from local variables by default, and do them selectively if an argument list is provided. So someone, in the past, thought about this and decided that it is best to always require an explicit list of variables for interpolation. This pep is trying to undo that decision. Why? What was the reason to always require an explicit list of variables? Didn't they think that it would be convenient to automatically interpolate from locals? What was it that made them decide against it? Isn't that reason still relevant? Without answering these questions, I think it is not wise to continue with this pep.

masida 11y ago

I agree. For me the automatic "pulling" of local variables from the context feels like "magic", and I think that's an undesirable property for a programming language. Of course, PEP498 has the same issue.

kerkeslager 11y ago
> For me the automatic "pulling" of local variables from the context feels like "magic", and I think that's an undesirable property for a programming language. Sounds like "Explicit is better than implicit" from the Tao of Python.

czinck 11y ago

That string interpolation was one of my least favorite things about Perl. We tended to have "$"s in strings just because of the usecase, and I was so afraid of that accidentally being interpolated that I never used double quotes, and instead used single quotes. Single quotes in Perl don't interpolate \n, so this "feature" made me write more code rather than less.

nokcha 11y ago

>With format and % functions, you will be able to spot the variable in the argument list, which is part of the code itself. That is not always true, e.g.: >>> x = 2 >>> print("x = {x}".format(**vars())) x = 2

noobermin 11y ago

For 1, it might be a matter of taste/familiarity. For me, interpolation in Julia makes string formatting easier to understand, at least for short strings. The issue is Julia's interpolation (I hope to god to be wrong about this, if it's wrong, someone correct me) doesn't have format specifiers, which put me in a pickle a few days ago. For 2, can you expand upon this? Not a challenge, but I'm not able to imagine how this would be a security concern, and this might be a failure of my understanding here.

imakesnowflakes 11y ago
>can you expand upon this.. It is more of a matter of breaking a general principle, which is don't mix executable stuff (expressions) with non-executable stuff (strings) implicitly. This has been a frequent cause of various security issues in the past eg: Sql injection, xss, various remote code execution vulnerabilities. Strings should be dumb and without any ambiguity. On top of breaking this general principle of not mixing data and code, this pep also want to introduce numerous rules regarding various edge cases, which further makes it harder to reason about it, which increases the chances of slipping a vulnerability. For example, right now, you see a long string, you only need to look at the argument list to see what possible things it can do. Because the string itself is dumb, it cannot lie, and whatever execution that is required to produce that string, happens in the context of code itself. With this pep, this changes. Now a string is not dumb. It is smart. It can do 'stuff' on its own. It can 'hide' things, it can lie and masquerade as something innocent. I think this is bad. Take an example of PHP. You can embedd php code in what ever content. In fact you can embedd php code in a valid image file in the metadata fields, and pass it as an Image. if you can call the image file as a script, then the embedded php code will execute to do your bidding. This has to be one of the most commonly used technique to hack sites running php. Here is one from last day [1]. Those are some of my reasons for the concerns..I know I am not still giving anything specific. But if we could easily think specific cases about how something could be exploited, we wouldn't be implementing that in the first place. So sometimes we must rely on general principles learned from the past while assessing the issues associated with something. Hence my concerns. [1] https://www.reddit.com/r/PHP/comments/3gq3mh/my_site_was_hacked_php_injection_can_anybody/ https://www.reddit.com/r/PHP/comments/3gq3mh/my_site_was_hac...

yoha 11y ago

Another point from the discussion was that there are already three ways to do string formatting in Python: 1. `"Value: %i" % value` 2. `"Value: {}".format(value)` 3. `string.Template('Value: $value').substitute(value=value)` However, the Zen of Python (https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ or run `import this` in a Python interpreter) says "There should be one-- and preferably only one --obvious way to do it.".

dragonwriter 11y ago

> 2. Security concerns regarding automatic evaluation of expressions inside the strings. How are there security concerns? Its a kind of string literal that is expanded into a calls to builtin formatting functions at compile time, so there is no more security concern with evaluating expressions in it then there is with evaluating expressions in the non-string parts of your code. > Also, why was format and % made in such a way as to require an explicit list of variables? What was the reasoning behind it? Is that reason no longer relevant? You can use those without an explicit list of variables, its optional to use explicit variables for clarity (though in many cases the natural naming will also make it redundant in simple cases.)

imakesnowflakes 11y ago
>How are there security concerns? It is more about breaking a general principle of not mixing executable stuff and non-executable stuff. I have written more about it here. https://news.ycombinator.com/item?id=10063637 https://news.ycombinator.com/item?id=10063637 >its optional to use explicit variables for clarity I don't think it is optional. If it was optional, then the behavior would be to interpolate from local variables by default, and do them selectively if an argument list is provided. So someone, in the past, thought about this and decided that it is best to always require an explicit list of variables for interpolation. This pep is trying to undo that decision. Why? What was the reason to always require an explicit list of variables? Didn't they think that it would be convenient to automatically interpolate from locals? What was it that made them decide against it? Isn't that reason still relevant? Without answering these questions, I think it is not wise to continue with this pep.