1. 19
  1. 2

    I hope they also add a way to evaluate the f-string bindings at runtime. I keep running into places where I want to define f{foo} but have foo not be bound until the f-string is used at runtime. You can’t do that.

    There’s a bunch of workarounds. Using str.format() is probably the best, but the language format() understands is different from f-string’s templates. You can get real f-strings but only by doing eval or inspect hacks, discussion here: https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings

    1. 2

      I keep running into places where I want to define f{foo} but have foo not be bound until the f-string is used at runtime. You can’t do that.

      Yeah, as you mentioned there are some ugly work arounds – you can kind of use a lambda and partial as another example (not that I would necessarily recommend it though):

      >>> thing = lambda _: f"I like {x} {y}"
      >>> t = functools.partial(thing, None)
      >>> x = "pickles"
      >>> y = "on saturdays"
      >>> t()
      'I like pickles on saturdays'
      >>> y = "on sundays"
      >>> t()
      'I like pickles on sundays'
      
      1. 2

        str.format() is not a workaround, f-strings do exactly what str.format() is doing, it’s just a syntactic sugar for that. It worked before and working since then to just construct a format string and use it with str.format().

        1. 3

          You are wrong. str.format() has very different semantic and inner working than f-strings. str.format format string are not even reusable for f-string. See https://docs.python.org/3/library/string.html#formatstrings. You can’t even eval arbitrary python with str.format, only access attributes or index or the given parameters.

          1. 3

            I might have worded poorly, but I’m not wrong. What I meant was that after evaluating f-strings, they work the same way, which I thought not worth mentioning, because obviously evaluation is the whole point of f-strings over str.format().