I think most people who have tried f-strings have found them handy. Could we transition to making default string literal into an f-string? I think there is a smooth migration path. f-strings without embedded expressions already compile to the same bytecode as normal string literals. I.e. no overhead. The issue will be literal strings that contain the f-string format characters. We could add a future import, e.g. from __future__ import fstring_literals that would make all literal strings in the module into f-strings. In some future release, we could warn about literal strings in modules without the future import that contain f-string format characters. Eventually, we can change the default. To make migration easier, we can provide a source-to-source translation tool. It is quite simple to do that using the tokenizer module.
This would break code that uses str.format everywhere for very little benefit. On Tue, Dec 5, 2017 at 4:19 PM, Neil Schemenauer <nas-python-ideas@arctrix.com> wrote:
I think most people who have tried f-strings have found them handy. Could we transition to making default string literal into an f-string? I think there is a smooth migration path.
f-strings without embedded expressions already compile to the same bytecode as normal string literals. I.e. no overhead. The issue will be literal strings that contain the f-string format characters.
We could add a future import, e.g.
from __future__ import fstring_literals
that would make all literal strings in the module into f-strings. In some future release, we could warn about literal strings in modules without the future import that contain f-string format characters. Eventually, we can change the default.
To make migration easier, we can provide a source-to-source translation tool. It is quite simple to do that using the tokenizer module. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Dec 6, 2017 at 8:19 AM, Neil Schemenauer <nas-python-ideas@arctrix.com> wrote:
I think most people who have tried f-strings have found them handy. Could we transition to making default string literal into an f-string? I think there is a smooth migration path.
f-strings without embedded expressions already compile to the same bytecode as normal string literals. I.e. no overhead. The issue will be literal strings that contain the f-string format characters.
We could add a future import, e.g.
from __future__ import fstring_literals
that would make all literal strings in the module into f-strings. In some future release, we could warn about literal strings in modules without the future import that contain f-string format characters. Eventually, we can change the default.
To make migration easier, we can provide a source-to-source translation tool. It is quite simple to do that using the tokenizer module.
No. Definitely not. It'd lead to all manner of confusion ("why can't I put braces in my string?"), and it's unnecessary. When you want interpolation, you put *one letter* in front of the string, and it means that most strings aren't magical pieces of executable code. Tiny advantage, large potential disadvantage. ChrisA
On 5 December 2017 at 19:23, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Dec 6, 2017 at 8:19 AM, Neil Schemenauer <nas-python-ideas@arctrix.com> wrote:
I think most people who have tried f-strings have found them handy. Could we transition to making default string literal into an f-string? I think there is a smooth migration path.
f-strings without embedded expressions already compile to the same bytecode as normal string literals. I.e. no overhead. The issue will be literal strings that contain the f-string format characters.
We could add a future import, e.g.
from __future__ import fstring_literals
that would make all literal strings in the module into f-strings. In some future release, we could warn about literal strings in modules without the future import that contain f-string format characters. Eventually, we can change the default.
To make migration easier, we can provide a source-to-source translation tool. It is quite simple to do that using the tokenizer module.
No. Definitely not. It'd lead to all manner of confusion ("why can't I put braces in my string?"), and it's unnecessary. When you want interpolation, you put *one letter* in front of the string, and it means that most strings aren't magical pieces of executable code. Tiny advantage, large potential disadvantage.
One more big NO here - strings are _data_ not code - this little fact had made Python easier to learn for decades. If you need interpolation, and therefore, code that is run in the context the string is declared, just use f-strings. But f-strings are not static data, they are objects aware of the point in the source code file they are declared - a very different beast from ordinary strings.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Dec 6, 2017 at 8:59 AM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
One more big NO here - strings are _data_ not code - this little fact had made Python easier to learn for decades. If you need interpolation, and therefore, code that is run in the context the string is declared, just use f-strings. But f-strings are not static data, they are objects aware of the point in the source code file they are declared - a very different beast from ordinary strings.
To be technically accurate, an f-string isn't an object at all - it's an expression. There's no way to refer to an unevaluated f-string. ChrisA
participants (5)
-
Chris Angelico -
Joao S. O. Bueno -
Joseph Jevnik -
Neil Schemenauer -
Serhiy Storchaka