On 08/10/2015 01:26 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > >> Which brought to mind a certain thought. While I don't like: >> >> f'My name is {name}, my age next year is {age+1}' >> >> I wouldn't have any similar objection to: >> >> 'My name is {name}, my age next year is {age+1}'.scope_format() >> >> Or >> >> scope_format('My name is {name}, my age next year is {age+1}') >> >> I realize that these could be completely semantically equivalent... but the >> function or method call LOOKS LIKE a runtime operation, while a one letter >> prefix just doesn't look like that (especially to beginners whom I might >> teach). > > I fear that this is actually worse than the f-string concept. f-strings, > as far as I understand, are literals. (Well, not exactly literals.) You > cannot say: > > # this can't happen (I think?) > expr = 'age + 1' > result = f'blah blah blah {' + expr + '}' > > and inject the expression into the f-string. That makes them a little > weaker than eval(), and hence a little safer.
Correct. f-strings only work on literals. They essentially convert the f-string literal into an expression (which is not strictly specified in the PEP, but it has examples). > But scope_format would > have to be eval in disguise, since it receives a string as argument, > and it can't know where it came from or how it came to be: > > # pretend that expr comes from, say, a web form > expr = 'age + 1}{os.system("echo Pwned!") and ""' > result = scope_format( > 'My name is {name}, my age next year is {' + expr + '}' > ) > > It's a dilemma, because I'm completely with you in your discomfort in > having something which looks like a string literal actually be a > function of sorts; but turning it into an actual function makes it more > dangerous, not less. > > I think I would be happy with f-strings, or perhaps i-strings if we use > Nick's ideas about internationalisation, and limit what they can > evaluate to name lookups, attribute lookups, and indexing, just like > format(). > > We can always relax that restriction in the future, if necessary, but > it's a lot harder to tighten it. This desire, which many people have expressed, is not completely lost on me. Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com