3 ms·

I don't know the history here, but it seems like Python could have saved a lot of pain by jumping straight to this solution (which has been in Ruby for upwards

I don't know the history here, but it seems like Python could have saved a lot of pain by jumping straight to this solution (which has been in Ruby for upwards of 20 years), instead of going via two solutions that seem strictly worse ("%s" interpolation and "{}".format()).

joshuamorton 4y ago
it's difficult to say that .format and %s are both strictly worse (I think "{}.format()" is strictly better than %s, but both are a bit orthogonal to f-strings because both are lazily applied. F-strings evaluate locals immediately, but .format can be called later. That is, concretely, f-strings are almost equivalent to `"".format(*locals())`, but f-strings fail for cases where, for example, the string to be formatted itself is not available at "compile" time.
- pmontra 4y ago
  You can use eval to trasform a string to f string and evaluate it. Of course format is better in that case. https://stackoverflow.com/questions/44757222/transform-string-to-f-string https://stackoverflow.com/questions/44757222/transform-strin...
- masklinn 4y ago
  > I think "{}.format()" is strictly better than %s It’s not, because it’s way too powerful. A user-provided printf string is not much of an issue, a user-provided str.format one very much is, as provides significant traversal capabilities.
  - joshuamorton 4y ago
    Is the .format sublanguage notably stronger than the %-one? I know in c, for example, the printf sublanguage can be used to do turing-complete things, but I didn't think that was possible in either in python.
    - masklinn 4y ago
      > Is the .format sublanguage notably stronger than the %-one? Yes, it allows arbitrary attribute traversal as well as broad indexing. The % sublangage is a lot more restrictive and doesn’t suffer from the arbitrary reading of the C version (if you format an object that wasn’t passed in you get an error not a read off of the stack or a register). I don’t think format is anywhere near turing complete, but it allows significant information querying and retrieval (https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/). Both still allow for resource exhaustion but that’s what it is.
pydry 4y ago
.format has fewer escaping headaches.
pmontra 4y ago
Agreed. There are things that languages must get right at the very beginning or be plagued by inconveniences forever. This is one of them. I got a number of bugs and test failures because I forgot an f before a string with interpolated values. Python is rooted in the 80s. Maybe Guido didn't get the idea because maybe his background was only with languages without interpolation. Example: C has argument replacement with printf("%d", 42) and no interpolation.
- sakjur 4y ago
  I think I would keep the f-prefix if I were to do a Python dialect from scratch with lessons learned. Making { a special character in any string seems excessive and prone to user injected rogue values that are hard to catch in all places of a large system. Having the slightly safer types of strings be the default seems prudent.
- henrydark 4y ago
  It's interesting to note that the creator of C and his well known friend also created m4 in the 70's, and it's very similar to "string interpolation", maybe even taken to the extreme. I was actually program-wise "raised" by The C Programming Language in the early 90's, and I only found out about m4 a month ago.
samwillis 4y ago
That doesn't really work, both of the other systems date back literal decades. F-Strings were implemented in 2015 as a complete new thing, inspired by other languages. In order to implement F-Stings, and due to limitations in the CPython language parser, F-Strings used to have a separate parser. Because of this there were restriction on what Python expressions could be embedded in an F-String. In 2020 CPython replaced is parser with a much more capable one. Now they are moving the F-String parsing to be part of the CPython parser proper, this is allowing them to lift many of the restrictions within F-Strings. "Formalising F-Strings" isn't a particularly good title, "Lifting the restrictions in F-String would be better".
tgv 4y ago
They could have saved even more pain by doing print() and unicode strings straight from the start, and by adding strict typing, and by finding a better solution for def __hack__(), but here we are.
- BiteCode_dev 4y ago
  Sure. From version 1 even. The one that shared an era with pokemon version 1, on the original black and white gameboy. Because it was so clear from the beginning, even if emoji didn't exist, cpu had no core, ruby hasn't been invented yet, and people were sharing the source code on floppy disk.
thijsvandien 4y ago
You would be surprised how much hate f-strings got when they were first proposed/implemented. :)
- BiteCode_dev 4y ago
  That's something most people don't realize. The walrus got heat. F-string got heat. match/case got heat. Unicode in python 3 got 15 years of trolling. Every single time you make a proposal, you have to make a compromise between: - what the infrastructure and style of the language allows - the resources you have - the desire for staying compat - the desire for staying modern - the pressure of people wanting a new toy - the pressure of people hating any kinda change You cannot flip a switch and "make the language better".
  - smitty1e 4y ago
    I have yet to ever need the walrus.
    - BiteCode_dev 4y ago
      I used it 3 times yesterday (usually for re.match). But I've been coding 15 years without it.
BiteCode_dev 4y ago
Yeah, why did we even had that assembly stuff? We should have had rust from the start! Seriously, python was born in 1991, 4 years BEFORE Java existed. And it barely had any funding until 2010. Insight is 20/20 but this is not how tech works. You are limited by knowledge, resources, politics, legacy, compatibility commitment and so on. Not to mention you can simply get it wrong. Would have been funny if the whole world moved out of unicode and we got stuck with it forever. Usually, you know something is a standard only when people complain you adopted it too late because everyone else did. Like Java that used XML for all serialization and got suck with it for 15 years while we all moved to JSON. Or utf-7 that is still used by IMAP because they did the wrong call. Yes, utf-7. What, you though utf8 was the only unicode standard? No, no, no. There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned. People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. Everything about text has been a fight for death to this day, for all programming languages. This includes formatting. We have "%s" because... of printf() in C. Let that sinks in.
- haberman 4y ago
  > People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. I mentioned that Ruby had this for "upwards of 20 years." I was vague on the timeline because I didn't know for sure how long it had been. After reading your message I looked into it and it looks like Ruby supported "#{expr}" since at least Ruby 0.95, in 1995: https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog.rb#L58 https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog... This is not to mention Perl, awk, shell, and Tcl, which had syntax like $FOO for even longer. Ruby's solution existed before all of the following PEPs, which added different varieties of string formatting to Python: - PEP 215 – String Interpolation (2000) (superseded by PEP 292) - PEP 292 – Simpler String Substitutions (2002), added string.Template() - PEP 3101 – Advanced String Formatting (2006), added str.format() - PEP 498 – Literal String Interpolation (2015), added f'' I get that language design is hard, and it's difficult to have the final answer right away. But it's not as if this idea was unknown or untested when Python introduced other home-grown solutions. When Python proposed f strings in 2015, it imitated a design that had been in Ruby for almost 20 years at that point.
- 4y ago

joshuamorton 4y ago

it's difficult to say that .format and %s are both strictly worse (I think "{}.format()" is strictly better than %s, but both are a bit orthogonal to f-strings because both are lazily applied. F-strings evaluate locals immediately, but .format can be called later. That is, concretely, f-strings are almost equivalent to `"".format(*locals())`, but f-strings fail for cases where, for example, the string to be formatted itself is not available at "compile" time.

pmontra 4y ago
You can use eval to trasform a string to f string and evaluate it. Of course format is better in that case. https://stackoverflow.com/questions/44757222/transform-string-to-f-string https://stackoverflow.com/questions/44757222/transform-strin...
masklinn 4y ago
> I think "{}.format()" is strictly better than %s It’s not, because it’s way too powerful. A user-provided printf string is not much of an issue, a user-provided str.format one very much is, as provides significant traversal capabilities.
- joshuamorton 4y ago
  Is the .format sublanguage notably stronger than the %-one? I know in c, for example, the printf sublanguage can be used to do turing-complete things, but I didn't think that was possible in either in python.
  - masklinn 4y ago
    > Is the .format sublanguage notably stronger than the %-one? Yes, it allows arbitrary attribute traversal as well as broad indexing. The % sublangage is a lot more restrictive and doesn’t suffer from the arbitrary reading of the C version (if you format an object that wasn’t passed in you get an error not a read off of the stack or a register). I don’t think format is anywhere near turing complete, but it allows significant information querying and retrieval (https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/ https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/). Both still allow for resource exhaustion but that’s what it is.

pydry 4y ago

.format has fewer escaping headaches.

pmontra 4y ago

Agreed. There are things that languages must get right at the very beginning or be plagued by inconveniences forever. This is one of them. I got a number of bugs and test failures because I forgot an f before a string with interpolated values. Python is rooted in the 80s. Maybe Guido didn't get the idea because maybe his background was only with languages without interpolation. Example: C has argument replacement with printf("%d", 42) and no interpolation.

sakjur 4y ago
I think I would keep the f-prefix if I were to do a Python dialect from scratch with lessons learned. Making { a special character in any string seems excessive and prone to user injected rogue values that are hard to catch in all places of a large system. Having the slightly safer types of strings be the default seems prudent.
henrydark 4y ago
It's interesting to note that the creator of C and his well known friend also created m4 in the 70's, and it's very similar to "string interpolation", maybe even taken to the extreme. I was actually program-wise "raised" by The C Programming Language in the early 90's, and I only found out about m4 a month ago.

samwillis 4y ago

That doesn't really work, both of the other systems date back literal decades. F-Strings were implemented in 2015 as a complete new thing, inspired by other languages. In order to implement F-Stings, and due to limitations in the CPython language parser, F-Strings used to have a separate parser. Because of this there were restriction on what Python expressions could be embedded in an F-String. In 2020 CPython replaced is parser with a much more capable one. Now they are moving the F-String parsing to be part of the CPython parser proper, this is allowing them to lift many of the restrictions within F-Strings. "Formalising F-Strings" isn't a particularly good title, "Lifting the restrictions in F-String would be better".

tgv 4y ago

They could have saved even more pain by doing print() and unicode strings straight from the start, and by adding strict typing, and by finding a better solution for def __hack__(), but here we are.

BiteCode_dev 4y ago
Sure. From version 1 even. The one that shared an era with pokemon version 1, on the original black and white gameboy. Because it was so clear from the beginning, even if emoji didn't exist, cpu had no core, ruby hasn't been invented yet, and people were sharing the source code on floppy disk.

thijsvandien 4y ago

You would be surprised how much hate f-strings got when they were first proposed/implemented. :)

BiteCode_dev 4y ago
That's something most people don't realize. The walrus got heat. F-string got heat. match/case got heat. Unicode in python 3 got 15 years of trolling. Every single time you make a proposal, you have to make a compromise between: - what the infrastructure and style of the language allows - the resources you have - the desire for staying compat - the desire for staying modern - the pressure of people wanting a new toy - the pressure of people hating any kinda change You cannot flip a switch and "make the language better".
- smitty1e 4y ago
  I have yet to ever need the walrus.
  - BiteCode_dev 4y ago
    I used it 3 times yesterday (usually for re.match). But I've been coding 15 years without it.

BiteCode_dev 4y ago

Yeah, why did we even had that assembly stuff? We should have had rust from the start! Seriously, python was born in 1991, 4 years BEFORE Java existed. And it barely had any funding until 2010. Insight is 20/20 but this is not how tech works. You are limited by knowledge, resources, politics, legacy, compatibility commitment and so on. Not to mention you can simply get it wrong. Would have been funny if the whole world moved out of unicode and we got stuck with it forever. Usually, you know something is a standard only when people complain you adopted it too late because everyone else did. Like Java that used XML for all serialization and got suck with it for 15 years while we all moved to JSON. Or utf-7 that is still used by IMAP because they did the wrong call. Yes, utf-7. What, you though utf8 was the only unicode standard? No, no, no. There are utf-7, utf-8, utf-16 (JS uses that) and utf-32 (C# uses that) in use. And more exist that abandoned. People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. Everything about text has been a fight for death to this day, for all programming languages. This includes formatting. We have "%s" because... of printf() in C. Let that sinks in.

haberman 4y ago
> People seems to be under the illusion that this stuff is easy, or obvious. Sure. In 2022. I mentioned that Ruby had this for "upwards of 20 years." I was vague on the timeline because I didn't know for sure how long it had been. After reading your message I looked into it and it looks like Ruby supported "#{expr}" since at least Ruby 0.95, in 1995: https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog.rb#L58 https://github.com/nobu/ruby-1.0/blob/master/sample/tkdialog... This is not to mention Perl, awk, shell, and Tcl, which had syntax like $FOO for even longer. Ruby's solution existed before all of the following PEPs, which added different varieties of string formatting to Python: - PEP 215 – String Interpolation (2000) (superseded by PEP 292) - PEP 292 – Simpler String Substitutions (2002), added string.Template() - PEP 3101 – Advanced String Formatting (2006), added str.format() - PEP 498 – Literal String Interpolation (2015), added f'' I get that language design is hard, and it's difficult to have the final answer right away. But it's not as if this idea was unknown or untested when Python introduced other home-grown solutions. When Python proposed f strings in 2015, it imitated a design that had been in Ruby for almost 20 years at that point.
4y ago