3 ms·

I'm in the "wish it was more explicit" camp. Would a fmt function be that terrible? fmt("{a} {b} {c}", a=a, b=b, c=c) If you want to save typing, maybe us

I'm in the "wish it was more explicit" camp. Would a fmt function be that terrible? fmt("{a} {b} {c}", a=a, b=b, c=c) If you want to save typing, maybe use :a instead of {a}. Or ?a would have made plain old ? a nice positional variant: fmt("?a ? ?", a=a, b, c) The main benefit of the fmt function is that it requires no syntax changes to the language and is trivially provided by a third party library for all past versions of Python. That being said this ship has sailed. I guess I just take a more conservative approach to syntax changes than most. Update: a bit sad to see my votes fluctuating wildly on this post. Please don't use votes to support or disagree with me: that's not what they're for. Please vote only based on whether you find this relevant.

mixmastamyk 11y ago
It is explicit, in that one must use the f'' prefix. There are no syntax changes as u'', b'', and r'' already exist. Positionals make bugs more likely.
- schmichael 11y ago
  It is implicit in that the interpolated values are specified anywhere in scope, not inline as with every other formatting option. I consider specifying the values or variables alongside the formatting string a requirement to be considered explicit, but I can see how it's a matter of opinion.
  - sametmax 11y ago
    @decorator def decorated Is doing: decorated = decorator(decorated) The switch is implicit too. It's syntaxic sugar to gain a pratical and elegant syntax for a common use case. It's not going to introduce vulnerability. It's going to make your code easier to write and read. It's going to make bug easier to spot in formating. It's going to make shell sessions easier.
    - schmichael 11y ago
      The manipulation (@dec) is still right next to the thing being manipulated (def dec). I'm not trying to be pedantic. It really does affect readability when syntactic sugar's affect spans an entire scope. Whether or not that effect on readability is greater or less than the gain by the syntactic sugar is always a matter of opinion. Obviously my opinion is out of line with Python's core devs.
- schmichael 11y ago
  It is a syntax change as before f"" was a syntax error: >>> f"foo" File "<stdin>", line 1 f"foo" ^ SyntaxError: invalid syntax
  - mixmastamyk 11y ago
    I suppose technically true, though similar to adding a function that didn't exist before. The syntax extension part of the feature (adding a letter to the grammar) is minuscule.
  - schmichael 11y ago
    > ... though similar to adding a function that didn't exist before. This is not true and exactly the distinction I'm trying to make: Adding new packages, functions, objects, etc. can all be backported to older versions and alternative implementations. They also require no updates to ASTs, linters, syntax highlighters, static analysis tools etc. Adding new syntax is backward incompatible (unless it's added as a from __future__ import to new old releases) and requires changes to all tools that parse Python syntax (the interpreter, ASTs, linters, transpilers, etc).
    - mixmastamyk 11y ago
      Ok, true, though I would argue that it isn't entirely new syntax but rather a variation of an existing one. It is a shame that linters will have to add a letter to their grammar also, but I argue that the everyday usability and readability for millions will outweigh this drawback.
scrollaway 11y ago
There's a fantastic "more explicit" version of it: str.format. This really is just an implicit version of str.format(). I just don't understand why such a significant syntax change would make it into python when it deviates so much from their usual mantra.
- mixmastamyk 11y ago
  Guido is not a purity robot, and has been looking for a way to have this feature since perl and python were duking it out in the early nineties. Practicality beats purity. It isn't a large syntax change, string prefixes have existed since the beginning.
  - sametmax 11y ago
    Yes. "Practicality beats purity". This part of the zen of Python, too many people forget about it. People forget that Python is also about readability, and ease of code exploration is the shell. Fstring is a feature to make that even better.
pvg 11y ago
https://news.ycombinator.com/item?id=117171 https://news.ycombinator.com/item?id=117171
- schmichael 11y ago
  Ha, well, I was I wrong. Thanks for the correction.

mixmastamyk 11y ago

It is explicit, in that one must use the f'' prefix. There are no syntax changes as u'', b'', and r'' already exist. Positionals make bugs more likely.

schmichael 11y ago
It is implicit in that the interpolated values are specified anywhere in scope, not inline as with every other formatting option. I consider specifying the values or variables alongside the formatting string a requirement to be considered explicit, but I can see how it's a matter of opinion.
- sametmax 11y ago
  @decorator def decorated Is doing: decorated = decorator(decorated) The switch is implicit too. It's syntaxic sugar to gain a pratical and elegant syntax for a common use case. It's not going to introduce vulnerability. It's going to make your code easier to write and read. It's going to make bug easier to spot in formating. It's going to make shell sessions easier.
  - schmichael 11y ago
    The manipulation (@dec) is still right next to the thing being manipulated (def dec). I'm not trying to be pedantic. It really does affect readability when syntactic sugar's affect spans an entire scope. Whether or not that effect on readability is greater or less than the gain by the syntactic sugar is always a matter of opinion. Obviously my opinion is out of line with Python's core devs.
schmichael 11y ago
It is a syntax change as before f"" was a syntax error: >>> f"foo" File "<stdin>", line 1 f"foo" ^ SyntaxError: invalid syntax
- mixmastamyk 11y ago
  I suppose technically true, though similar to adding a function that didn't exist before. The syntax extension part of the feature (adding a letter to the grammar) is minuscule.
- schmichael 11y ago
  > ... though similar to adding a function that didn't exist before. This is not true and exactly the distinction I'm trying to make: Adding new packages, functions, objects, etc. can all be backported to older versions and alternative implementations. They also require no updates to ASTs, linters, syntax highlighters, static analysis tools etc. Adding new syntax is backward incompatible (unless it's added as a from __future__ import to new old releases) and requires changes to all tools that parse Python syntax (the interpreter, ASTs, linters, transpilers, etc).
  - mixmastamyk 11y ago
    Ok, true, though I would argue that it isn't entirely new syntax but rather a variation of an existing one. It is a shame that linters will have to add a letter to their grammar also, but I argue that the everyday usability and readability for millions will outweigh this drawback.

scrollaway 11y ago

There's a fantastic "more explicit" version of it: str.format. This really is just an implicit version of str.format(). I just don't understand why such a significant syntax change would make it into python when it deviates so much from their usual mantra.

mixmastamyk 11y ago
Guido is not a purity robot, and has been looking for a way to have this feature since perl and python were duking it out in the early nineties. Practicality beats purity. It isn't a large syntax change, string prefixes have existed since the beginning.
- sametmax 11y ago
  Yes. "Practicality beats purity". This part of the zen of Python, too many people forget about it. People forget that Python is also about readability, and ease of code exploration is the shell. Fstring is a feature to make that even better.

pvg 11y ago

https://news.ycombinator.com/item?id=117171 https://news.ycombinator.com/item?id=117171

schmichael 11y ago
Ha, well, I was I wrong. Thanks for the correction.