On 08/07/2015 04:12 AM, Guido van Rossum wrote:
Maybe in the end the f-string proposal is the right one -- it's minimally obtrusive and yet explicit, *and* backwards compatible? This isn't saying I'm giving up on always-interpolation; there seems to be at least an even split between languages that always interpolate (PHP?), languages that have a way to explicitly disable it (like single quotes in shell), and languages that require some sort of signal (like C#).
I think one of the advantages of f-strings is they are explicitly created in the context of where the scope is defined. That scope includes non-locals too. So locals, and globals is a narrower selection than the defined static scope. Non-locals can't mask globals if they aren't included. So "...".format(*locals(), **globals()) is not the same as when the names are explicitly supplied as keywords. If it is opened up to dynamic scope, all bets are off. That hasn't been suggested, but when functions use locals and globals as arguments, I think that is the security concern. One of questions I have is, will there be a way to create an f-string other than by a literal. So far, I think no, because it's not an object, but a protocol. f"..." ---> "...".format(...). That doesn't mean we can't have a function to do that. Currently the best way would be to do eval('f"..."'), but it wouldn't be exactly the same because eval does not include the non-local part of the scope. It seems that hasn't been an an issue for other things, so maybe it's not an issue here as well. If all strings get scanned, I think it could complicate how strings act in various contexts. For example when a string is used both as f-string and then gets used again as a template or pattern. That suggests there should be a way to turn that scanning off for some strings. (?) So far I'm -1 on all strings, but +.25 on the explicit f-string. (Still waiting to see the PEP before I give it a full +1.) Cheers, Ron