Pythons f-strings are still static formation, you just can move party of the code into the fstring. (Ignoring eval and similar.)
The scary part about the vulnerability was that string >inputs< could dynamically delegate it's content to some magic information fetching system which by default allows accessing remote content in a way which by design can lead to remote code execution.
I have no idea who though non static format strings are a good idea.
Or an information fetching system which can trigger remote code execution.
Or that this system doesn't require stric whitelisting.
I see. Imagine that a LdapAddress class helpfully overrides __str__() in the way it happened in Log4j. Then a completely innocuous f-string that just prints the value of such an object in a log line could trigger execution of that code. No need to even have an expression that calls anything explicitly.
If I saw __str__ making network requests, I’d consider it a strong anti-pattern too. Sure, if a library was doing it then I might not find out, but that still puts the issue squarely on the library doing questionable things, rather than the entire logging framework itself.
The scary part about the vulnerability was that string >inputs< could dynamically delegate it's content to some magic information fetching system which by default allows accessing remote content in a way which by design can lead to remote code execution.
I have no idea who though non static format strings are a good idea.
Or an information fetching system which can trigger remote code execution.
Or that this system doesn't require stric whitelisting.