5 ms·

To this novice, the "Old" way looks so much better.

• sametmax 7y ago
  What old way ? %, zfill, strftime, or some hack with len() ? Having a unified syntax with all formatting needs is a big deal.
• qquark 7y ago
  This is maybe not directly visible in the parent comment, and particularly not on the website, that is compatible with old versions of python also, but to me there's a huge difference in usability also in the ability to use variable names in the current scope without additional verbose crap by default. This seems secondary to a lot of people, but to me that changes everything: >>> x = 1 >>> f"{x}" '1' This is much more readable than: >>> "{x}".format(x=x) '1' >>> "{}".format(x) '1' It makes the code immensely more readable than having to count parameters, especially for long strings with a lot of data in them. Counting is for computers, not programmers; I shouldn't have to count anything for such a trivial task. So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases. The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.
  • collyw 7y ago
    I disagree, especially when using named parameters. The new style is too implicit.
    • hannasanarion 7y ago
      How is it implicit? Every insertion is expressed in exactly the place where it will print. It's way more explicit than having a placeholder and a value on completely different parts of the expression.
      • collyw 7y ago
        > It's way more explicit than having a placeholder and a value on completely different parts of the expression. No its not.
        • majewsky 7y ago
          "My name is {}, I'm {}'{}'' tall and live in {}".format(name, location, feet, inches) This error is much better hidden than in the equivalent: f"My name is {name}, I'm {location}'{feet}'' tall and live in {inches}."
          • collyw 7y ago
            I did mention named parameters, you are using positional parameters to make your point. You don't even list the variables in your example. That seems pretty implicit to me. I think this is more explicit: "My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7)
            • isaacremuant 7y ago
              Your example is not representative because you're using literals. Your actual example would be: "My name is {name}, I'm {feet} tall and live in {location}.".format(name=name, location=location, feet=feet) And with f-strings: f"My name is {name}, I'm {feet} tall and live in {location}." f-strings is clearly more readable, concise and actually faster to run.
              • collyw 7y ago
                The literals were just an example. And personally I find it more explicit, which is my original point. If its faster to run, then fair enough.
                • cecilpl2 7y ago
                  Using your example, I think "My name is {name}, I'm {feet} tall and live in {location}.".format(name="Bob", location="USA", feet=7) is less explicit than "My name is Bob, I'm 7 feet tall and live in USA."
  • civility 7y ago
    I see your point, but the syntax inside of fstrings forms an entirely new sub-language (DSL). I can look at old python and know exactly how the .format() calls parse with positional and named keyword arguments, but looking at the fstrings I need to be familiar with all of the new magic. I've heard similar complaints about the loop macro in Common Lisp, and this feels a bit like shell or Tcl strings which could mean anything (arguments to sed/awk or paths to widgets/urls). However, I guess people are familiar with regular expressions as a completely foreign nested language (DSL), so this isn't much different than that.
• collyw 7y ago
  I agree, it seems to be getting away from "explicit over implicit".
• smugworth 7y ago
  I love F-strings, my only gripe is the chosen syntax for invoking them. For starters, F may or may not be capitalized, so these two lines are identical. F"My string with {interpolated_value}" f'My string with {interpolated_value}' Like using apostrophes or quotation marks to enclose strings (or F-strings), I find myself wasting time questioning the trivial notion of whether to capitalize or not. I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string. "This is my ${interpolated_value} string" 'This is my plain old string' But these are nitpicks, and it's really too late to implement something like that.
  • kragen 7y ago
    > I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string. That's Perl's syntax, from about 15 years before Groovy, whippersnapper. Off my lawn, now.
    • dragonwriter 7y ago
      Yeah, Groovy got it from Ruby which got it from Perl.
      • kragen 7y ago
        Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $. Oh, although I guess Perl got that syntax from the Bourne shell…
        • dragonwriter 7y ago
          > Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $. Huh, I could have sworn that I remembered that Groovy has taken it from Ruby. Incidentally, Ruby uses just # for variables, it uses #{} for arbitrary expressions. A common style prefers #{} even where # alone works, though.