Evaluation of variable as f-string

[Thomas Passin]

On 1/27/2023 5:54 PM, Rob Cliffe via Python-list wrote:
> Whoa! Whoa! Whoa!
> I appreciate the points you are making, Chris, but I am a bit taken 
> aback by such forceful language.

I generally agree with asking for what the intent is.  In this case it 
seems pretty clear that the OP wants to use these string fragments as 
templates, and he needs to be able to insert variables into them at 
runtime, not compile time.

So I think a good response would have been roughly

"It looks like you want to use these strings as templates, is that 
right?  If not, please tell us what you are trying to do, because it's 
hard to help without knowing that.  If it's right, here's a way you 
could go about it."

Short and amiable.

> On 27/01/2023 19:18, Chris Angelico wrote:
>> On Sat, 28 Jan 2023 at 05:31, Rob Cliffe via Python-list
>> <python-list at python.org> wrote:
>>> On 23/01/2023 18:02, Chris Angelico wrote:
>>>> Maybe, rather than asking for a way to treat a string as code, ask for
>>>> what you ACTUALLY need, and we can help?
>>>>
>>>> ChrisA
>>> Fair enough, Chris, but still ISTM that it is reasonable to ask (perhaps
>>> for a different use-case) whether there is a way of evaluating a string
>>> at runtime as if it were an f-string.  We encourage people to ask
>>> questions on this list, even though the answer will not always be what
>>> they're hoping for.
>> No, it's not, because that's the "how do I use X to do Y" problem.
>> Instead, just ask how to do *what you actually need*. If the best way
>> to do that is to eval an f-string, then someone will suggest that.
>> But, much much much more likely, the best way to do it would be
>> something completely different. What, exactly? That's hard to say,
>> because *we don't know what you actually need*. All you tell us is
>> what you're attempting to do, which there is *no good way to achieve*.
> If the above is addressed to the OP, I can't answer for him.
> If it's addressed to me:  How about if I wanted a program (a learning 
> tool) to allow the user to play with f-strings?
> I.e. to type in a string, and then see what the result would be if it 
> had been an f-string?
> I suspect there are other use cases, but I confess I can't think of one 
> right now.
>>
>>> I appreciate that the answer may be "No, because it would be a lot of
>>> work - and increase the maintenance burden - to support a relatively
>>> rare requirement".
>> What about: "No, because it's a terrible TERRIBLE idea, requires that
>> you do things horribly backwards, and we still don't even know what
>> you're trying to do"?
>>
>>> Perhaps someone will be inspired to write a function to do it. 😎
>> See, we don't know what "it" is, so it's hard to write a function
>> that's any better than the ones we've seen.
> Again, if this is addressed to the OP: I'm not his keeper. 😁
> If it's addressed to me: "it" means a function that will take a string 
> and evaluate it at runtime as if it were an f-string.  Sure, with 
> caveats and limitations.  And indeed Thomas Passim found this partial 
> solution on Stack Overflow:
> def effify(non_f_str: str):
>      return eval(f'f"""{non_f_str}"""')
>>   Using eval() to construct
>> an f-string and then parse it is TERRIBLE because:
>>
>> 1) It still doesn't work in general, and thus has caveats like "you
>> can't use this type of quote character"
>> 2) You would have to pass it a dictionary of variables, which also
>> can't be done with full generality
>> 3) These are the exact same problems, but backwards, that led to
>> f-strings in the first place
>> 4) eval is extremely slow and horrifically inefficient.
> I understand these limitations.  Nonetheless I can conceive that there 
> may be scenarios where it is an acceptable solution (perhaps the 
> learning tool program I suggested above).
> Addressing your points specifically:
>      1) I believe the quote character limitation could be overcome. It 
> would need a fair amount of work, for which I haven't (yet) the time or 
> inclination.
>      2) Yes in general you would have to pass it one dictionary, maybe 
> two.  I don't see this as an insuperable obstacle.  I am not sure what 
> you mean by "can't be done with full generality" and perhaps that's not 
> important.
>      3) Not sure I understand this.
>      4) On the fairly rare occasions that I have used eval(), I can't 
> remember speed ever being a consideration.
>>
>> For some reason, str.format() isn't suitable, but *you haven't said
>> why*, so we have to avoid that in our solutions. So, to come back to
>> your concern:
>>
>>> We encourage people to ask
>>> questions on this list, even though the answer will not always be what
>>> they're hoping for.
>> Well, yes. If you asked "how can I do X", hoping the answer would be
>> "with a runtime-evaluated f-string", then you're quite right - the
>> answer might not be what you were hoping for. But since you asked "how
>> can I evaluate a variable as if it were an f-string", the only
>> possible answer is "you can't, and that's a horrible idea".
> I hope that I have shown that this is a somewhat dogmatic response.
>>
>> Don't ask how to use X to do Y. Ask how to do Y.
> Good advice.
> Best wishes
> Rob Cliffe
>>
>> ChrisA
>