3 ms·

Until the newer way comes along and then there's n+1 ways.

pas 7y ago
The new ways come for a reason. And the new ways should respect PEP20, meaning they should work for the old use cases, so that everyone can start using the new ways as soon as they can upgrade to that version. Now, of course Python is interpreted and packages are shipped as raw source code and this makes things harder for library authors, because were there a compile/transpile step, they could write using the new and shiny obvious ways, all the while providing compiled blobs (or transpiled libs) targeting multiple versions.
- wund3rb4r88 7y ago
  So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language, and obliges a non-insignificant userbase to adapt? Technological purity or scratching some philosophical itch would be a poor reason, IMO, given how broad the externalized costs run. So is it provably easier to reason around the new style? Reduce computing time by an order of magnitude (in the modern era where compute cycles and memory are hella cheap)? Code is to be written so it’s understandable and useful for humans first, right? How does a third syntax for a solved usecase offer real value to the user base? Or are we just being sycophants of so-called experts, peddling some novel “look”. Experts who largely built a rep on first mover advantage, but have since seen that excuse for being deified evaporate as the rest of world learned all the same tricks?
  - SoReadyToHelp 7y ago
    > So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language The new syntax is more like other modern languages, not less.
  - simonh 7y ago
    >that looks nothing like string formatting syntax used in any other language PHP echo "There are $apples apples and $bananas bananas."; Ruby puts "I have #{apples} apples" TCL puts "I have $apples apples." Typescript console.log(`I have ${apples} apples`); Python print(f"I have {apples} apples") Looks pretty similar to me, and if you like understand-ability by humans so much I think f-strings win hands down. But if you disagree, there's plenty of code out there still using % strings or .format() and they're not going anywhere any time soon.
    - olooney 7y ago
      Python's string format is also very similar to the "double mustache" convention widely used in web development. The following template string: "I have {{apples}} apples" To my certain knowledge this works in Jinja2, Django templates, Vue.js, mustache.js, handlebars.js, and probably many others. PEP 498 mentions that they did look at other languages to see what was supported: https://www.python.org/dev/peps/pep-0498/#similar-support-in-other-languages https://www.python.org/dev/peps/pep-0498/#similar-support-in... And they link to this Wikipedia article, which lists many examples: https://en.wikipedia.org/wiki/String_interpolation https://en.wikipedia.org/wiki/String_interpolation Scanning through that, my impression is that "there is nothing new under the sun" and aside from an occasional "$" or "#" prefix, or a willfully arbitrary deviation like ColdFusion, the conventions can all be traced the Bourne shell /bin/sh/ which was released in 1979. Prior to that, the prinf() syntax was presumably the most common, but it's obscure. Does anyone know if the ${variable} convention was original with the Bourne shell, or if it can be traced back further?
      - fanf2 7y ago
        I am surprised to find that the 6th edition shell had only $1 etc positional parameter expansion, and named shell variables are not described in its man page http://man.cat-v.org/unix-6th/1/sh http://man.cat-v.org/unix-6th/1/sh
    - poium99 7y ago
      Anecdotally, the only language in that list I encounter anymore is Python. TypeScript is a closest second. I’m rather done with this interpreted, dynamic typed, language and the hell holes they dig us into. DRY could be applied to more contexts than code logic: stop rewriting language features unless there is more than a subjective win of “looks nicer.” or performance is improved by an order of magnitude. The conversations the Python community should be having are not “once again we must discuss and consider a solution to a solved problem.” When that’s the sort of progress the language devs are prioritizing, it’s a sign to me they’re out of ideas or incapable of fixing the bigger flaws.
simonh 7y ago
Sure, but is Python better for having f-strings or worse?

pas 7y ago

The new ways come for a reason. And the new ways should respect PEP20, meaning they should work for the old use cases, so that everyone can start using the new ways as soon as they can upgrade to that version. Now, of course Python is interpreted and packages are shipped as raw source code and this makes things harder for library authors, because were there a compile/transpile step, they could write using the new and shiny obvious ways, all the while providing compiled blobs (or transpiled libs) targeting multiple versions.

wund3rb4r88 7y ago
So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language, and obliges a non-insignificant userbase to adapt? Technological purity or scratching some philosophical itch would be a poor reason, IMO, given how broad the externalized costs run. So is it provably easier to reason around the new style? Reduce computing time by an order of magnitude (in the modern era where compute cycles and memory are hella cheap)? Code is to be written so it’s understandable and useful for humans first, right? How does a third syntax for a solved usecase offer real value to the user base? Or are we just being sycophants of so-called experts, peddling some novel “look”. Experts who largely built a rep on first mover advantage, but have since seen that excuse for being deified evaporate as the rest of world learned all the same tricks?
- SoReadyToHelp 7y ago
  > So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language The new syntax is more like other modern languages, not less.
- simonh 7y ago
  >that looks nothing like string formatting syntax used in any other language PHP echo "There are $apples apples and $bananas bananas."; Ruby puts "I have #{apples} apples" TCL puts "I have $apples apples." Typescript console.log(`I have ${apples} apples`); Python print(f"I have {apples} apples") Looks pretty similar to me, and if you like understand-ability by humans so much I think f-strings win hands down. But if you disagree, there's plenty of code out there still using % strings or .format() and they're not going anywhere any time soon.
  - olooney 7y ago
    Python's string format is also very similar to the "double mustache" convention widely used in web development. The following template string: "I have {{apples}} apples" To my certain knowledge this works in Jinja2, Django templates, Vue.js, mustache.js, handlebars.js, and probably many others. PEP 498 mentions that they did look at other languages to see what was supported: https://www.python.org/dev/peps/pep-0498/#similar-support-in-other-languages https://www.python.org/dev/peps/pep-0498/#similar-support-in... And they link to this Wikipedia article, which lists many examples: https://en.wikipedia.org/wiki/String_interpolation https://en.wikipedia.org/wiki/String_interpolation Scanning through that, my impression is that "there is nothing new under the sun" and aside from an occasional "$" or "#" prefix, or a willfully arbitrary deviation like ColdFusion, the conventions can all be traced the Bourne shell /bin/sh/ which was released in 1979. Prior to that, the prinf() syntax was presumably the most common, but it's obscure. Does anyone know if the ${variable} convention was original with the Bourne shell, or if it can be traced back further?
    - fanf2 7y ago
      I am surprised to find that the 6th edition shell had only $1 etc positional parameter expansion, and named shell variables are not described in its man page http://man.cat-v.org/unix-6th/1/sh http://man.cat-v.org/unix-6th/1/sh
  - poium99 7y ago
    Anecdotally, the only language in that list I encounter anymore is Python. TypeScript is a closest second. I’m rather done with this interpreted, dynamic typed, language and the hell holes they dig us into. DRY could be applied to more contexts than code logic: stop rewriting language features unless there is more than a subjective win of “looks nicer.” or performance is improved by an order of magnitude. The conversations the Python community should be having are not “once again we must discuss and consider a solution to a solved problem.” When that’s the sort of progress the language devs are prioritizing, it’s a sign to me they’re out of ideas or incapable of fixing the bigger flaws.

simonh 7y ago

Sure, but is Python better for having f-strings or worse?