Mailing List Archive

On Tue, 24 Jan 2023 at 04:56, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>
> Hi there,
>
> is there an easy way to evaluate a string stored in a variable as if it
> were an f-string at runtime?
>
> ...
>
> This is supposedly for security reasons. However, when trying to emulate
> this behavior that I wanted (and know the security implications of), my
> solutions will tend to be less secure. Here is what I have been thinking
> about:

If you really want the full power of an f-string, then you're asking
for the full power of eval(), and that means all the security
implications thereof, not to mention the difficulties of namespacing.
Have you considered using the vanilla format() method instead?

But if you really REALLY know what you're doing, just use eval()
directly. I don't really see what you'd gain from an f-string. At very
least, work with a well-defined namespace and eval whatever you need
in that context.

Maybe, rather than asking for a way to treat a string as code, ask for
what you ACTUALLY need, and we can help?

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

Op 23/01/2023 om 17:24 schreef Johannes Bauer:
> Hi there,
>
> is there an easy way to evaluate a string stored in a variable as if
> it were an f-string at runtime?
>
> I.e., what I want is to be able to do this:
>
> x = { "y": "z" }
> print(f"-> {x['y']}")
>
> This prints "-> z", as expected. But consider:
>
> x = { "y": "z" }
> s = "-> {x['y']}"
> print(s.format(x = x))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> KeyError: "'y'"
>
> Even though
>
> s = "-> {x}"
> print(s.format(x = x))
>
> Prints the expected "-> {'y': 'z'}".
>
I am probably missing something but is there a reason why the following
wouldn't do what you want:

x = { "y": "z" }
s = "-> {target}"
print(s.format(target = x['y']))
--
https://mail.python.org/mailman/listinfo/python-list

On 1/25/2023 1:26 PM, Antoon Pardon wrote:
> Op 23/01/2023 om 17:24 schreef Johannes Bauer:
>> Hi there,
>>
>> is there an easy way to evaluate a string stored in a variable as if
>> it were an f-string at runtime?
>>
>> I.e., what I want is to be able to do this:
>>
>> x = { "y": "z" }
>> print(f"-> {x['y']}")
>>
>> This prints "-> z", as expected. But consider:
>>
>> x = { "y": "z" }
>> s = "-> {x['y']}"
>> print(s.format(x = x))
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> KeyError: "'y'"
>>
>> Even though
>>
>> s = "-> {x}"
>> print(s.format(x = x))
>>
>> Prints the expected "-> {'y': 'z'}".
>>
> I am probably missing something but is there a reason why the following
> wouldn't do what you want:
>
> x = { "y": "z" }
> s = "-> {target}"
> print(s.format(target = x['y']))

Stack overflow to the rescue:

Search phrase: "python evaluate string as fstring"

https://stackoverflow.com/questions/47339121/how-do-i-convert-a-string-into-an-f-string

def effify(non_f_str: str):
return eval(f'f"""{non_f_str}"""')

print(effify(s)) # prints as expected: "-> z"
--
https://mail.python.org/mailman/listinfo/python-list

On 23/01/2023 18:02, Chris Angelico wrote:
> On Tue, 24 Jan 2023 at 04:56, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>> Hi there,
>>
>> is there an easy way to evaluate a string stored in a variable as if it
>> were an f-string at runtime?
>>
>> ...
>>
>> This is supposedly for security reasons. However, when trying to emulate
>> this behavior that I wanted (and know the security implications of), my
>> solutions will tend to be less secure. Here is what I have been thinking
>> about:
> If you really want the full power of an f-string, then you're asking
> for the full power of eval(), and that means all the security
> implications thereof, not to mention the difficulties of namespacing.
> Have you considered using the vanilla format() method instead?
>
> But if you really REALLY know what you're doing, just use eval()
> directly. I don't really see what you'd gain from an f-string. At very
> least, work with a well-defined namespace and eval whatever you need
> in that context.
>
> 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.
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".
Perhaps someone will be inspired to write a function to do it. ????
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

On 25/01/2023 19:38, Thomas Passin wrote:
>
> Stack overflow to the rescue:
>
> Search phrase:  "python evaluate string as fstring"
>
> https://stackoverflow.com/questions/47339121/how-do-i-convert-a-string-into-an-f-string
>
>
> def effify(non_f_str: str):
>     return eval(f'f"""{non_f_str}"""')
>
> print(effify(s))  # prints as expected: "-> z"
Duh!  Am I the only one who feels stupid not thinking of this?
Although of course it won't work if the string already contains triple
double quotes.
I believe this could be got round with some ingenuity (having the effify
function parse the string and replace genuine (not embedded in
single-quotes) triple double quotes with triple single quotes, though
there are some complications).
And the effify function can't be put in its own module unless it can be
passed the globals and/or locals dictionaries as needed for eval to
use.  Something like this:

def effify(non_f_str, glob=None, loc=None):
    return eval(f'f"""{non_f_str}"""',
        glob if glob is not None else globals(),
        loc if loc is not None else locals())

Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

On Sat, 28 Jan 2023 at 05:31, Rob Cliffe via Python-list
<python-list@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*.

> 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. 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.

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".

Don't ask how to use X to do Y. Ask how to do Y.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

Am 23.01.23 um 19:02 schrieb Chris Angelico:

>> This is supposedly for security reasons. However, when trying to emulate
>> this behavior that I wanted (and know the security implications of), my
>> solutions will tend to be less secure. Here is what I have been thinking
>> about:
>
> If you really want the full power of an f-string, then you're asking
> for the full power of eval(),

Exactly.

> and that means all the security
> implications thereof,

Precisely, as I had stated myself.

> not to mention the difficulties of namespacing.

Not an issue in my case.

> Have you considered using the vanilla format() method instead?

Yes. It does not provide the functionality I want. Not even the utterly
trivial example that I gave. To quote myself again, let's say I have an
arbitrary dictionary x (with many nested data structures), I want an
expression to be evaluated that can access any members in there.

x = { "y": "z" }
s = "-> {x['y']}"
print(s.format(x = x))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: "'y'"

I also want to be able to say things like {'x' * 100}, which .format()
also does not do.

In other words: I want the evaluation of a variable as an f-string.


> But if you really REALLY know what you're doing, just use eval()
> directly.

I do, actually, but I hate it. Not because of the security issue, not
because of namespaces, but because it does not reliably work:

>>> s = "{\"x\" * 4}"
>>> eval("f'" + s + "'")
'xxxx'

As I mentioned, it depends on the exact quoting. Triple quotes only
shift the problem. Actually replacing/escaping the relevant quotation
marks is also not trivial.

> I don't really see what you'd gain from an f-string.

The full power of eval.

> At very
> least, work with a well-defined namespace and eval whatever you need
> in that context.

That's what I'm doing.

> Maybe, rather than asking for a way to treat a string as code, ask for
> what you ACTUALLY need, and we can help?

I want to render data from a template using an easily understandable
syntax (like an f-string), ideally using native Python. I want the
template to make use of Python code constructs AND formatting (e.g.
{x['time']['runtime']['seconds'] // 60:02d}).

Cheers,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list

Am 23.01.23 um 17:43 schrieb Stefan Ram:
> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>> x = { "y": "z" }
>> s = "-> {x['y']}"
>> print(s.format(x = x))
>
> x = { "y": "z" }
> def s( x ): return '-> ' + x[ 'y' ]
> print( s( x = x ))

Except this is not at all what I asked for. The string "s" in my example
is just that, an example. I want to render *arbitrary* strings "s"
together with arbitrary dictionaries "x".

Cheers,
Johannes

--
https://mail.python.org/mailman/listinfo/python-list

Am 25.01.23 um 20:38 schrieb Thomas Passin:

>> x = { "y": "z" }
>> s = "-> {target}"
>> print(s.format(target = x['y']))
>
> Stack overflow to the rescue:

No.

> Search phrase:  "python evaluate string as fstring"
>
> https://stackoverflow.com/questions/47339121/how-do-i-convert-a-string-into-an-f-string
>
> def effify(non_f_str: str):
>     return eval(f'f"""{non_f_str}"""')
>
> print(effify(s))  # prints as expected: "-> z"

Great.

s = '"""'

> def effify(non_f_str: str):
> return eval(f'f"""{non_f_str}"""')
>
> print(effify(s)) # prints as expected: "-> z"

>>> print(effify(s))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in effify
File "<string>", line 1
f"""""""""
^
SyntaxError: unterminated triple-quoted string literal (detected at line 1)

This is literally the version I described myself, except using triple
quotes. It only modifies the underlying problem, but doesn't solve it.

Cheers,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list

Am 27.01.23 um 20:18 schrieb Chris Angelico:

> All you tell us is
> what you're attempting to do, which there is *no good way to achieve*.

Fair enough, that is the answer. It's not possible.

>> 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. 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"

Exactly my observation as well, which is why I was thinking there's
something else I missed.

> 2) You would have to pass it a dictionary of variables, which also
> can't be done with full generality

Nonsense. I only am passing a SINGLE variable to eval, called "x". That
is fully general.

> 3) These are the exact same problems, but backwards, that led to
> f-strings in the first place

I don't know what you mean by that.

> 4) eval is extremely slow and horrifically inefficient.

Let me worry about it.

> For some reason, str.format() isn't suitable,

I don't understand why you fully ignore literally the FIRST example I
gave in my original post and angrily claim that you solution works when
it does not:

x = { "y": "z" }
s = "-> {x['y']}"
print(s.format(x = x))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: "'y'"

This. Does. Not. Work.

I want to pass a single variable as a dictionary and access its members
inside the expression.

> but *you haven't said
> why*,

Yes I have, see above.

> 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".

"You can't" would have been sufficient. Pity. Your judgement is
unnecessary and, frankly, uncalled for as well. Multiple instances you
claim that you have no idea what I am doing so how would you even begin
to judge a solution as fit or unfit?

> Don't ask how to use X to do Y. Ask how to do Y.

You don't have to be angry that my question does not have a solution. I
will manage and so might you.

Cheers,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list

Am 27.01.23 um 21:43 schrieb Johannes Bauer:
> I don't understand why you fully ignore literally the FIRST example I
> gave in my original post and angrily claim that you solution works when
> it does not:
>
> x = { "y": "z" }
> s = "-> {x['y']}"
> print(s.format(x = x))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> KeyError: "'y'"
>
> This. Does. Not. Work.

It's because "you're holding it wrong!". Notice the error message; it
says that the key 'y' does not exist.


(base) Apfelkiste:Abschlussmeeting chris$ ipython
Python 3.8.8 (default, Apr 13 2021, 12:59:45)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.22.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: x = { "y": "z" }

In [2]: s = "-> {x[y]}"

In [3]: print(s.format(x = x))
-> z

In [4]:

Christian
--
https://mail.python.org/mailman/listinfo/python-list

Whoa! Whoa! Whoa!
I appreciate the points you are making, Chris, but I am a bit taken
aback by such forceful language.

On 27/01/2023 19:18, Chris Angelico wrote:
> On Sat, 28 Jan 2023 at 05:31, Rob Cliffe via Python-list
> <python-list@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

--
https://mail.python.org/mailman/listinfo/python-list

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@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
>

--
https://mail.python.org/mailman/listinfo/python-list

On Sat, 28 Jan 2023 at 10:08, Rob Cliffe via Python-list
<python-list@python.org> wrote:
>
> Whoa! Whoa! Whoa!
> I appreciate the points you are making, Chris, but I am a bit taken
> aback by such forceful language.

The exact same points have already been made, but not listened to.
Sometimes, forceful language is required in order to get people to
listen.

> 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.

Use the REPL, which will happily evaluate f-strings in their original
context, just like any other code would. You're already eval'ing, so
it's exactly what you'd expect. This is not the same thing as "typing
in a string", though - it's typing in code and seeing what the result
would be. (Except to the extent that source code can be considered a
string.)

> 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 that's what I am saying is a terrible terrible idea. It will
evaluate things in the wrong context, it has all the normal problems
of eval, and then it introduces its own unique problems with quote
characters.

> And indeed Thomas Passim found this partial
> solution on Stack Overflow:
> def effify(non_f_str: str):
> return eval(f'f"""{non_f_str}"""')

You can find anything on Stack Overflow. Just because you found it
there doesn't mean it's any good - even if it's been massively
upvoted.

> 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.

No problem. Here, solve it for this string:

eval_me = ' f"""{f\'\'\'{f"{f\'{1+2}\'}"}\'\'\'}""" '

F-strings can be nested, remember.

> 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.

>>> def func():
... x = 1
... class cls:
... y = 2
... print(f"{x=} {y=}")
... print(locals())
...
>>> func()
x=1 y=2
{'__module__': '__main__', '__qualname__': 'func.<locals>.cls', 'y': 2}

Maybe you don't care. Maybe you do. But locals() is not the same as
"all names currently available in this scope". And, this example is
definitely not something I would recommend, but good luck making this
work with eval:

>>> def func():
... x = 1
... print(f"{(x:=2)}")
... print(x)
...
>>> func()
2
2
... x = 1
... print(eval("(x:=2)", globals(), locals()))
... print(x)
...
>>> func()
2
1

> 3) Not sure I understand this.

Before f-strings existed, one of the big problems with "just use
str.format_map" was that you can't just pass it locals() to get all
the available names. You also can't eval arbitrary code and expect to
get the same results, even if you pass it globals and locals. And
various other considerations here - the exact issues seen here, but
flipped on their heads. So the obvious question is: why not just use
str.format_map?

> > 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.

And I hope that I have shown that it is fully justified.

> > Don't ask how to use X to do Y. Ask how to do Y.
> Good advice.

Exactly. As I have shown, asking how to use f-strings to achieve this
is simply not suitable, and there's no useful way to discuss other
than to argue semantics. If we had a GOAL to discuss, we could find
much better options.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 1/27/2023 3:33 PM, Johannes Bauer wrote:
> Am 25.01.23 um 20:38 schrieb Thomas Passin:
>
>>> x = { "y": "z" }
>>> s = "-> {target}"
>>> print(s.format(target = x['y']))
>>
>> Stack overflow to the rescue:
>
> No.
>
>> Search phrase:  "python evaluate string as fstring"
>>
>> https://stackoverflow.com/questions/47339121/how-do-i-convert-a-string-into-an-f-string
>>
>> def effify(non_f_str: str):
>>      return eval(f'f"""{non_f_str}"""')
>>
>> print(effify(s))  # prints as expected: "-> z"
>
> Great.
>
> s = '"""'
>
> > def effify(non_f_str: str):
> >      return eval(f'f"""{non_f_str}"""')
> >
> > print(effify(s))  # prints as expected: "-> z"
>
> >>> print(effify(s))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 2, in effify
>   File "<string>", line 1
>     f"""""""""
>            ^
> SyntaxError: unterminated triple-quoted string literal (detected at line 1)
>
> This is literally the version I described myself, except using triple
> quotes. It only modifies the underlying problem, but doesn't solve it.

Ok, so now we are in the territory of "Tell us what you are trying to
accomplish". And part of that is why you cannot put some constraints on
what your string fragments are. The example I gave, copied out of your
earlier message, worked and now you are springing triple quotes on us.

Stop with the rock management already and explain (briefly if possible)
what you are up to.

--
https://mail.python.org/mailman/listinfo/python-list

On 1/27/2023 5:10 PM, Christian Gollwitzer wrote:
> Am 27.01.23 um 21:43 schrieb Johannes Bauer:
>> I don't understand why you fully ignore literally the FIRST example I
>> gave in my original post and angrily claim that you solution works
>> when it does not:
>>
>> x = { "y": "z" }
>> s = "-> {x['y']}"
>> print(s.format(x = x))
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> KeyError: "'y'"
>>
>> This. Does. Not. Work.
>
> It's because "you're holding it wrong!". Notice the error message; it
> says that the key 'y' does not exist.
>
>
> (base) Apfelkiste:Abschlussmeeting chris$ ipython
> Python 3.8.8 (default, Apr 13 2021, 12:59:45)
> Type 'copyright', 'credits' or 'license' for more information
> IPython 7.22.0 -- An enhanced Interactive Python. Type '?' for help.
>
> In [1]: x = { "y": "z" }
>
> In [2]: s = "-> {x[y]}"
>
> In [3]: print(s.format(x = x))
> -> z
>
> In [4]:
>
>     Christian

Oops, that's not quite what he wrote.

You: s = "-> {x[y]}" # Works
Him: s = "-> {x['y']}" # Fails

--
https://mail.python.org/mailman/listinfo/python-list

May I point out that some dynamic situations can in a sense be normalized?

The example below posits a dynamically allocated dictionary during run time.
But why can't you have a placeholder variable name in place and make your
placeholder a link to the dictionary (or other item) before invoking the
existing f-string with the placeholder built-in, rather than trying to
evaluate an F$B"t(B ???

Of course many situations may not have as much of a possible work-around.
But as so many have noted, we never got a really good explanation of what
the OP really wants to do. There have been replies that may be suitable
solutions and some clearly have potential to be security holes if you let
the users dynamically create strings to be evaluated.

In some languages, many of the facets of the language can be passed along as
a function with some name to be used in functional programming techniques
and this can be very useful. The "operator" module can be used for quite a
few things like operator.add or operator.__add__ or operator.concat and many
more. If the logic used to evaluate an f-string (and for that matter the
other string variants like b'..' and r'...') could be encapsulated in a
function like that, it would be potentially usable as in passing something
like dangerous_operator.f_string and a list of strings and having that
return a list of evaluated strings.

The fact that something like this is not known to the people here may hint
that it is not something considered safe to use by amateurs. But then again,
anyone who wants to can use eval() as Chris points out.

Of course, there may be other reasons too. An f-string is evaluated in a
context that may be different if a string is passed along and then looked at
in another context.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Stefan Ram
Sent: Friday, January 27, 2023 4:31 PM
To: python-list@python.org
Subject: Re: Evaluation of variable as f-string

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>>x = { "y": "z" }
>>>s = "-> {x['y']}"
>>>print(s.format(x = x))
>>x = { "y": "z" }
>>def s( x ): return '-> ' + x[ 'y' ]
>>print( s( x = x ))
>Except this is not at all what I asked for. The string "s" in my
>example is just that, an example. I want to render *arbitrary* strings "s"
>together with arbitrary dictionaries "x".

I take this to mean that you want to process a dictionary
name, a string and a dictionary that is only specified as
late as at run time.

import string

name = input( 'name of the dictionary? ' ) string_ = input( 'string? ' ) #
"-> {x['y']}"
dictionary = eval( input( 'dictionary? ' )) print( eval( 'f"""' + string_ +
'"""', {name:dictionary} ))

name of the dictionary? x
string? -> {x['y']}
dictionary? { 'y': 'z' }
-> z


--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

On 2023-01-27 20:56:49 -0500, Thomas Passin wrote:
> On 1/27/2023 5:10 PM, Christian Gollwitzer wrote:
> > Am 27.01.23 um 21:43 schrieb Johannes Bauer:
> > > x = { "y": "z" }
> > > s = "-> {x['y']}"
> > > print(s.format(x = x))
> > > Traceback (most recent call last):
> > > ?? File "<stdin>", line 1, in <module>
> > > KeyError: "'y'"
> > >
> > > This. Does. Not. Work.
> >
> > It's because "you're holding it wrong!". Notice the error message; it
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > says that the key 'y' does not exist.
[...]
> > In [1]: x = { "y": "z" }
> > In [2]: s = "-> {x[y]}"
> > In [3]: print(s.format(x = x))
> > -> z
> > In [4]:
>
> Oops, that's not quite what he wrote.
>
> You: s = "-> {x[y]}" # Works
> Him: s = "-> {x['y']}" # Fails

That was the point.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2023-01-27 21:43:09 +0100, Johannes Bauer wrote:
> x = { "y": "z" }
> s = "-> {x['y']}"
> print(s.format(x = x))
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> KeyError: "'y'"
>
> This. Does. Not. Work.
>
> I want to pass a single variable as a dictionary and access its members
> inside the expression.

You can do that (see other responses), but you can't have arbitrary
Python expressions inside a format string.

It works with f-strings because f-strings are a compiler construct. The
f-string never exists at run-time. Instead the compiler transforms
f"-> {x['y']}"
into the equivalent of
"-> " + format_value(x["y"]) + ""

So either you need to pass it to the Python compiler (via eval), or you
need to implement enough of a Python parser/interpreter to cover the
cases you are interested in. The latter might be an interesting
exercise, but I would suggest looking at existing template engines like
Jinja2 for production purposes.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2023-01-27 21:31:05 +0100, Johannes Bauer wrote:
> > But if you really REALLY know what you're doing, just use eval()
> > directly.
>
> I do, actually, but I hate it. Not because of the security issue, not
> because of namespaces, but because it does not reliably work:
>
> >>> s = "{\"x\" * 4}"
> >>> eval("f'" + s + "'")
> 'xxxx'

That's exactly the result I expected. What did you expect?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 27/01/2023 23:41, Chris Angelico wrote:
> On Sat, 28 Jan 2023 at 10:08, Rob Cliffe via Python-list
> <python-list@python.org> wrote:
>> Whoa! Whoa! Whoa!
>> I appreciate the points you are making, Chris, but I am a bit taken
>> aback by such forceful language.
> The exact same points have already been made, but not listened to.
> Sometimes, forceful language is required in order to get people to
> listen.
>
>> 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.
> Use the REPL, which will happily evaluate f-strings in their original
> context, just like any other code would. You're already eval'ing, so
> it's exactly what you'd expect. This is not the same thing as "typing
> in a string", though - it's typing in code and seeing what the result
> would be. (Except to the extent that source code can be considered a
> string.)
This is hypothetical, but I might want to work on a platform where the
REPL was not available.
>
>> 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 that's what I am saying is a terrible terrible idea. It will
> evaluate things in the wrong context, it has all the normal problems
> of eval, and then it introduces its own unique problems with quote
> characters.
With great respect, Chris, isn't it for the OP (or anyone else) to
decide - having been warned of the various drawbacks and limitations -
to decide if it's a terrible idea *for him*?  He's entitled to decide
that it's just what *he* needs, and that the drawbacks don't matter *for
him".  Just as you're entitled to disagree.
>
>> And indeed Thomas Passim found this partial
>> solution on Stack Overflow:
>> def effify(non_f_str: str):
>> return eval(f'f"""{non_f_str}"""')
> You can find anything on Stack Overflow. Just because you found it
> there doesn't mean it's any good - even if it's been massively
> upvoted.
>
>> 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.
> No problem. Here, solve it for this string:
>
> eval_me = ' f"""{f\'\'\'{f"{f\'{1+2}\'}"}\'\'\'}""" '
>
> F-strings can be nested, remember.
I remember it well.
As far as I can see (and I may well be wrong; thinking about this
example made my head hurt ????) this could be solved if PEP 701 were
implemented (so that f-string expressions can contain backslashes) but
not otherwise.
>
>> 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.
>>>> def func():
> ... x = 1
> ... class cls:
> ... y = 2
> ... print(f"{x=} {y=}")
> ... print(locals())
> ...
>>>> func()
> x=1 y=2
> {'__module__': '__main__', '__qualname__': 'func.<locals>.cls', 'y': 2}
Thanks for clarifying.
Hm.  So 'x' is neither in locals() nor in globals().  Which starts me
wondering (to go off on a tangent): Should there be a nonlocals()
dictionary?
>
> Maybe you don't care. Maybe you do. But locals() is not the same as
> "all names currently available in this scope". And, this example is
> definitely not something I would recommend, but good luck making this
> work with eval:
>
>>>> def func():
> ... x = 1
> ... print(f"{(x:=2)}")
> ... print(x)
> ...
>>>> func()
> 2
> 2
> ... x = 1
> ... print(eval("(x:=2)", globals(), locals()))
> ... print(x)
> ...
>>>> func()
> 2
> 1
Now that, I have to admit, IS a challenge!
>
>> 3) Not sure I understand this.
> Before f-strings existed, one of the big problems with "just use
> str.format_map" was that you can't just pass it locals() to get all
> the available names. You also can't eval arbitrary code and expect to
> get the same results, even if you pass it globals and locals. And
> various other considerations here - the exact issues seen here, but
> flipped on their heads. So the obvious question is: why not just use
> str.format_map?
>
What this underlines to me is what a good thing f-strings are.  And with
PEP 701 they will be IMO even better.
Just as when you were working on PEP 463 (Exception-catching
expressions) - which I still think would be a Good Thing - some research
I did made me realise how good the existing try/except/else/finally
mechanism actually is.  There's lots of Good Stuff in Python. ????
Best wishes
Rob


--
https://mail.python.org/mailman/listinfo/python-list

Am 28.01.23 um 02:51 schrieb Thomas Passin:

>> This is literally the version I described myself, except using triple
>> quotes. It only modifies the underlying problem, but doesn't solve it.
>
> Ok, so now we are in the territory of "Tell us what you are trying to
> accomplish". And part of that is why you cannot put some constraints on
> what your string fragments are.  The example I gave, copied out of your
> earlier message, worked and now you are springing triple quotes on us.

It works in this particular case, yes. Just like the example I gave in
my original case:

eval("f'" + s + "'")

"works" if there are no apostrophes used. And just like

eval("f\"" + s + "\"")

"works" if there are no quotation marks used.

I don't want to have to care about what quotation is used inside the
string, as long as it could successfully evaluate using the f-string
grammar.

> Stop with the rock management already and explain (briefly if possible)
> what you are up to.

I have a string. I want to evaluate it as if it were an f-string. I.e.,
there *are* obviously restrictions that apply (namely, the syntax and
semantics of f-strings), but that's it.

Best,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list

Am 28.01.23 um 00:41 schrieb Chris Angelico:
> On Sat, 28 Jan 2023 at 10:08, Rob Cliffe via Python-list
> <python-list@python.org> wrote:
>>
>> Whoa! Whoa! Whoa!
>> I appreciate the points you are making, Chris, but I am a bit taken
>> aback by such forceful language.
>
> The exact same points have already been made, but not listened to.
> Sometimes, forceful language is required in order to get people to
> listen.

An arrogant bully's rationale. Personally, I'm fine with it. I've been
to Usenet for a long time, in which this way of "educating" people was
considered normal. But I do think it creates a deterring, toxic
environment and reflects back to you as a person negatively.

>> 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.
>
> No problem. Here, solve it for this string:
>
> eval_me = ' f"""{f\'\'\'{f"{f\'{1+2}\'}"}\'\'\'}""" '
>
> F-strings can be nested, remember.

Exactly. This is precisely what I want to avoid. Essentially, proper
quotation of such a string requires to write a fully fledged f-string
parser, in which case the whole problem solves itself.

>>> Don't ask how to use X to do Y. Ask how to do Y.
>> Good advice.
>
> Exactly. As I have shown, asking how to use f-strings to achieve this
> is simply not suitable, and there's no useful way to discuss other
> than to argue semantics. If we had a GOAL to discuss, we could find
> much better options.

I was not asking how to use f-strings. I was asking to evaluate a string
*as if it were* an f-string. Those are two completely different things
which you entirely ignored.

In other words, if there were a magic function:

evalfstring(s, x = x)

That would have been the ideal answer. There does not seem to be one,
however. So I'm back to silly workarounds.

Cheers,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list

Am 27.01.23 um 23:10 schrieb Christian Gollwitzer:
> Am 27.01.23 um 21:43 schrieb Johannes Bauer:
>> I don't understand why you fully ignore literally the FIRST example I
>> gave in my original post and angrily claim that you solution works
>> when it does not:
>>
>> x = { "y": "z" }
>> s = "-> {x['y']}"
>> print(s.format(x = x))
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> KeyError: "'y'"
>>
>> This. Does. Not. Work.
>
> It's because "you're holding it wrong!". Notice the error message; it
> says that the key 'y' does not exist.

Ah, that is neat! I didn't know that. Thanks for the info.

In my case, I do also however want to have some functionality that
actually does math or even calls functions. That would be possible with
templates or f-strings, but not format:


x = { "t": 12345 }
s = "{x['t'] // 60:02d}:{x['t'] % 60:02d}"
print(s.format(x = x))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: "'t'"

and

s = "{x[t] // 60:02d}:{x[t] % 60:02d}"
print(s.format(x = x))

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Only '.' or '[' may follow ']' in format field specifier

but of course:

print(f"{x['t'] // 60:02d}:{x['t'] % 60:02d}")
205:45

Best,
Johannes
--
https://mail.python.org/mailman/listinfo/python-list