Should All Strings Become f-strings?
Should All Strings Become f-strings?
Posted May 2, 2020 16:56 UTC (Sat) by mb (subscriber, #50428)Parent article: The 2020 Python Language Summit
It forces every Python developer on earth to go through all their strings and check them for possible f-string formatting. We already went through all of our strings at the 2to3 conversion. Yes this time it's not as hard, because only immediates would be affected and a conversion tool could probably be written.
And all that just to prevent some easy to catch errors caused by missing f prefixes.
How's a missing f prefix different from a typo'ed f notation inside of the string anyway?
Posted May 3, 2020 16:41 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link]
Posted May 3, 2020 17:47 UTC (Sun)
by mirabilos (subscriber, #84359)
[Link] (5 responses)
Posted May 3, 2020 18:29 UTC (Sun)
by kooky (subscriber, #92468)
[Link] (4 responses)
'The numbers are {} and {}'.format(x,y)
Posted May 4, 2020 20:43 UTC (Mon)
by kevincox (subscriber, #93938)
[Link] (3 responses)
And you could trivially write a conversion tool that fixed your files and added the "import". It could even convert most `.format()` calls to native fstrings fairly easily.
Posted May 7, 2020 11:12 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
Posted May 7, 2020 13:52 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted May 10, 2020 21:57 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
My working assumption is that this syntax would have to be valid and available for a lengthy period before f-strings would actually become the default. Ideally, this would be long enough that even RHEL is no longer using the old versions, but maybe that's a bit too optimistic.
Fortunately, enabling the p prefix and the future import would not actually break any existing code, so it could be backported if desired. This actually happened with the Python 3 u and b prefixes, and I tend to assume the Python devs learned from that experience.
Posted May 4, 2020 7:50 UTC (Mon)
by rschroev (subscriber, #4164)
[Link] (1 responses)
There seems to be consensus that f-strings are the best thing ever ("the killer feature of Python 3.6"). I don't agree, but that's not even the point.
There is a fundamental difference between a string itself and formatting a string. That difference is there for a reason; don't mess with it! If you want to format a string, then format it. Explicitly.
> Smith conceded that p-strings make the language more complicated, but, he said, "There's going to be very few p's in the wild, and I think their explanation will be fairly obvious."
Smith wants to make things more simple; acknowledges his proposal would make the language more complicated instead; insists it doesn't matter.
What happened to "Explicit is better than implicit"? That's one of the main reasons I like Python. Recent changes are complicating the language but they don't bother me too much. This proposal is a game changer: it it gets accepted, Python will no longer be my language of choice for all kinds of scripts and tools.
Posted May 6, 2020 22:08 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
While I generally agree, "f-strings by default" is much less insane than some of the other programming languages I've worked with. Inform 7, among its many other oddities, treats all strings as *lazily-evaluated* f-strings, and thus the contents of a string may be different every time you print it! In effect, every string literal implicitly becomes a thunk, closure, or lambda (whichever terminology you prefer), and that lambda is implicitly evaluated by the I/O system whenever a string needs to be printed (there's also a function to force immediate evaluation, because Inform 7 is not Haskell). Fortunately, in the Python world, everyone has been very clear from the beginning not to go down that bizarre and implausible road.
(To be fair, Inform 7 does have reasons for doing this. It is predominantly used for writing text adventures, which naturally contain a ton of text substitutions, and so it dedicates an enormous amount of effort to making text substitutions look grammatical and reasonable in a wide variety of circumstances. For example, it has full support for plurals, verb conjugation, comma-delimited lists, and a variety of other "little things" that are annoying to do by hand. Making it as easy as possible for printed text to contain "natural-looking" variations is obviously concordant with that goal. Also, it was originally designed to compile to Z-machine, which has severe memory constraints, so deferring text substitution to the last possible moment is obviously preferable to building a large string in memory and having it sit there indefinitely.)
I would also argue that defaulting to f-strings would potentially be a violation of the "explicit is better than implicit" aspect of the Zen of Python. In general, I don't expect magic in my string declarations unless I explicitly say so. And I have a fair amount of code that leverages this to only activate the templating at a later phase rather than immediately, as defaulting to f-strings would do.
There are still problems with f-strings and internationalization, too...
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?
Should All Strings Become f-strings?