The Python Language Summit 2020 was held on April 15th and 16th. This is a meeting where developers of Python implementations (PyPy, etc. in addition to the original CPython) gather, rather than just a place to present each other, a meeting to discuss the current state and future of the language itself and the standard library and aim for agreement. And that.
Due to the spread of the coronavirus this year, it seems that it was held online without exception, but looking at the agenda for two days, it is quite interesting.
In this, I took up the first "Make all strings f strings" and [this blog post](https://pyfound.blogspot.com/2020/04/all-strings- I would like to briefly summarize what kind of discussion was made based on become-f-strings-python.html).
Before we get into the discussion, let's review what the f string is. The f string is a feature introduced in Python 3.6 that puts variables and expressions in part of the string and replaces them at runtime.
For example
>>> x = 1
>>> print(f"The value of x is{x}is")
The value of x is 1
It will be. If you try to do something similar before the introduction of the f string
print("The value of x is%d" % x)
Or
print("The value of x is{}is".format(x))
I was doing it. Either way, the place to replace with the variable and the place to specify the variable are separated, so it was difficult to understand and it was a part where bugs were likely to occur. This became easier at once with the introduction of the f string.
In other languages, for example JavaScript,
let x = 1
console.log(`The value of x is${x}is`)
You can write that, and Ruby, Scala, C #, etc. have similar functions, so it seems that you are in the tide of the times.
The function of the f string has been slightly extended in Python 3.8, for example.
>>> x = 1
>>> y = 2
>>> print(f"{x=}, {y=}, {x+y=}")
x=1, y=2, x+y=3
Can be done. In other words, by adding = to the end of {}, not only the value of the variable or expression but also the variable or expression itself will be included in the output. It's useful for a little debugging, so it's worth remembering.
A very useful f string as above. It seems that some people have moved from Python 2 to Python 3 because of this, but as it is used more often, dissatisfaction has come out. The discussion to solve it is the first agenda item for the Python Language Summit 2020. The agenda was submitted by Eric Smith, who originally wrote the PEP for the introduction of f strings in 2015.
This is the problem we are discussing here.
>>> x = 1
>>> print("The value of x is{x}is")
The value of x is{x}is
Do you understand? "Oh, I forgot to put the f in front of the string (^^; "".
To avoid this mistake, he's seen a programmer who prefixes every string with a f, with or without variable substitutions. So his suggestion is
"Default string is f string"
That is. In fact, when introducing the f string in 3.6, it seems that it was such a proposal at first, but it was rejected because it was a destructive change that was too big, and it settled down to the current f in mind.
In this proposal, the f character string is used with or without f, and an additional" p character string "is introduced. If the character string is preceded by p, the previous characters It was treated as a column. There is no deterioration in performance due to it.
On the other hand, the inventor Smith also knows that there are some problems, for example, he has to introduce a new string prefix such as p. Also, it will be a big change
from __future__ import all_fstrings
I want to enable this only when there is an import statement that says. Well, if you do so, you will not be able to remove it easily, so this proposal was rejected.
Participants commented on this proposal.
Yarko Tymciurak asked the question, "Why and how do you explain p to beginners? " Smith admitted that " p would make the language specification a little complicated, "but answered," in reality, p isn't used that much, and the explanation is pretty obvious." It was.
Some participants were willing to make this change, and Brett Cannon commented that "eliminating the f prefix would make it easier for beginners to learn Python. "
Larry Hastings said, "PHP strings have this kind of specification, and I think script kids really like it." But he said, "Oops, I forgot to add f. " To avoid it, I think it's a mistake that you'll notice right away, but do you change the language specifications just for that? "
Many participants agreed that the f string should have been the default from the beginning, but Paul Moore, Guido van Rossum (the founder of Python) and others are more harmful than profitable. I was worried that it would grow. And this agenda ended with the continuation of discussion in ML.
I personally agree with making the f string the default, but I thought it wouldn't be that easy. It was a short blog post, but I think it was good to see the participants carefully discussing the changes in the language specifications while considering various aspects.
Recommended Posts