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

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

On Sun, 29 Jan 2023 at 11:53, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> 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.
>

Not possible. An f-string can contain other f-strings, and it is
entirely possible to use EVERY quote type. So you can never add quotes
around the outside of a string and then evaluate it as an f-string,
without making sure that it doesn't already contain that string.

(That MAY be changing in a future version of Python, but it's currently true.)

ChrisA

On Sun, 29 Jan 2023 at 11:56, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
>
> 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.

Arrogant bully? Or someone who has tried *multiple times* to explain
to you that what you're asking for is IMPOSSIBLE, and you need to ask
a better question if you want a better answer?

If that's "bullying", then fine, ban me for bullying, and go find
somewhere else where you'll be coddled and told that your question is
fine, it's awesome, and yes, wouldn't it be nice if magic were a
thing.

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

They're not different things, because what you asked for is NOT
POSSIBLE without the caveats that I gave. It is *fundamentally not
possible* to "evaluate a string as if it were an f-string", other than
by wrapping it in an f-string and evaluating it - with the
consequences of that.

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

Right. Exactly. Now if you'd asked for what you REALLY need, maybe
there'd be a solution involving format_map, but no, you're so utterly
intransigent that you cannot adjust your question to fit reality.

If that makes me a bad guy, then fine. I'll be the bad guy.

But you're not going to change the laws of physics.

ChrisA

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>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.

(This message was written for Usenet. If you read it in a
mailing list or the Web, it has been stolen from Usenet.)

So, you want your run-time client or run-time user to have the
same choices as someone who is just writing python source code
and is using an f-string?

Then what about,

name = input( 'name of the dictionary? ' )
s = input( 'string? ' )
dictionary = eval( input( 'dictionary? ' ))
print( eval( s, {name:dictionary} ))

? Here are four transcripts:

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

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

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

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

.

On Sun, 29 Jan 2023 at 14:36, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>
> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> >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.
>
> (This message was written for Usenet. If you read it in a
> mailing list or the Web, it has been stolen from Usenet.)
>

I'm curious as to the copyright protections available to you, but if
you're going to threaten python-list's owners with legal action for
daring to rebroadcast a public post, I would have to recommend that
you get promptly banned from the list in order to reduce liability.

What's so bad about mailing lists that you don't want your messages to
be seen on them?

ChrisA

On 1/28/2023 2:50 PM, Johannes Bauer wrote:
> 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.

Well, yes, we do see that. What we don't see is what you want to
accomplish by doing it, and why you don't seem willing to accept some
restrictions on the string fragments so that they will evaluate correctly.

IOW, perhaps there is a more practical way to accomplish what you want.
Except that we don't know what that is.

Am 29.01.23 um 02:09 schrieb Chris Angelico:

>>> 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.
>
> Arrogant bully? Or someone who has tried *multiple times* to explain
> to you that what you're asking for is IMPOSSIBLE, and you need to ask
> a better question if you want a better answer?

In literally your first answer you resorted to aggressive language and
implied that what I asked wasn't what I actually wanted. It was.

Also note that in your first answer you did not answer "sorry, this is
not possible", which would have been completely sufficient as an answer.
Instead you tried your best at guesswork, implying I didn't know what I
was doing.

So, yes, absolutely toxic behavior. I fully stand by that judgement of mine.

I'll go a step further and again repeat that THIS sort of behavior is
what gives open source forums a bad rep. There's always a Lennart
Poettering, an Ulrich Drepper or maybe a Chris Angelico around who may
have great technical skill but think they can treat people like shit.

> If that's "bullying", then fine, ban me for bullying, and go find
> somewhere else where you'll be coddled and told that your question is
> fine, it's awesome, and yes, wouldn't it be nice if magic were a
> thing.

LOL, "ban you"? What the heck are you talking about, my friend?

I don't need to be coddled by you. I'm trying to give you the favor of
honest feedback, which is that you sound like an utter bully. If you
don't care, that is totally fine by me.

> They're not different things, because what you asked for is NOT
> POSSIBLE without the caveats that I gave. It is *fundamentally not
> possible* to "evaluate a string as if it were an f-string", other than
> by wrapping it in an f-string and evaluating it - with the
> consequences of that.

Yeah that sucks, unfortunately. But I'll live.

>> 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.
>
> Right. Exactly. Now if you'd asked for what you REALLY need, maybe
> there'd be a solution involving format_map, but no, you're so utterly
> intransigent that you cannot adjust your question to fit reality.

Does format_map do exactly what f-strings can do? Can I pass arbitrary
functions and Python expressions insode a format_map? No? Of course not.
Then it does not answer the question.

> If that makes me a bad guy, then fine. I'll be the bad guy.

Awww, it's adorable how you're trying to frame yourself as the victim.
I'll be here if you need a hug, buddy.

> But you're not going to change the laws of physics.

Yeah we'll have to disagree about the fact that it's the "laws of
physics" preventing a specific implementation of a Python function.

Cheers,
Johannes

Am 29.01.23 um 05:27 schrieb Thomas Passin:

> Well, yes, we do see that.  What we don't see is what you want to
> accomplish by doing it, and why you don't seem willing to accept some
> restrictions on the string fragments so that they will evaluate correctly.

I'll have to accept the restrictions. That's a good enough answer for
me, actually. I was just thinking that possibly there's something like
(made-up code):

x = { "foo": "bar" }
fstr = string.fstring_compile(s)
fstr.eval(x = x)

Which I didn't know about. It would make sense to me, but possibly not
enough of a usecase to make it into Python. The format() flavors do not

> IOW, perhaps there is a more practical way to accomplish what you want.
> Except that we don't know what that is.

Well, I don't know. I pretty much want a generic Python mechanism that
allows for exactly what f-strings do: execute arbitrary Python snippets
of code and format them in one go. In other words, I want to be able to
do things like that, given an *arbitrary* dictionary x and a string s
(which has the only restriction that its content needs to be vald
f-string grammar):

x = {
"d": 12,
"t": 12345,
"dt": datetime.datetime,
"td": datetime.timedelta
} s = "{x['d']:09b} {'->' * (x['d'] // 3)} {(x['dt'](2000, 1, x['d']) +
x['td'](120)).strftime('%y.%m.%d')} {'<-' * (x['d'] // 4)}"
q = magic_function(s, x = x)

and have "q" then be

'000001100 ->->->-> 00.05.11 <-<-<-'

I believe the closest solution would be using a templating mechanism
(like Mako), but that has slightly different syntax and doesn't do
string formatting as nice as f-strings do. f-strings really are the
perfect syntax for what I want to do.

Cheers,
Johannes

Am 28.01.23 um 02:56 schrieb Thomas Passin:
> 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
>
You might want to reconsider why I could have possibly written this
message....

Christian

On 2023-01-29 15:47:47 +1100, Chris Angelico wrote:
> On Sun, 29 Jan 2023 at 14:36, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> > (This message was written for Usenet. If you read it in a
> > mailing list or the Web, it has been stolen from Usenet.)
>
> I'm curious as to the copyright protections available to you, but if
> you're going to threaten python-list's owners with legal action for
> daring to rebroadcast a public post, I would have to recommend that
> you get promptly banned from the list in order to reduce liability.

Stefan had been banned for years because of this issue. In mid-2021
(wow, that long ago? I thought that was a lot more recently) his posts
started to appear again.

I don't know if this was a concious decision of the moderators, a
technical error or whether Stefan changed something which caused him to
escape the filter.

I don't think it matters. If someone posts to a Usenet group with the
full knowledge that it is gatewayed to a mailing list it is unreasonable
to expect the moderators of the list to jump through hoops to comply
with wishes hidden away in a non-standard header.

> What's so bad about mailing lists that you don't want your messages to
> be seen on them?

He's Stefan Ram :-).

hp

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

On 1/29/2023 6:09 AM, Christian Gollwitzer wrote:
> Am 28.01.23 um 02:56 schrieb Thomas Passin:
>> 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
>>
> You might want to reconsider why I could have possibly written this
> message....

I might .. or I might wish you had actually said what you wanted to
convey ...

On 2023-01-29 10:18:00 +0100, Johannes Bauer wrote:
> Am 29.01.23 um 05:27 schrieb Thomas Passin:
> > IOW, perhaps there is a more practical way to accomplish what you want.
> > Except that we don't know what that is.
>
> Well, I don't know. I pretty much want a generic Python mechanism that
> allows for exactly what f-strings do: execute arbitrary Python snippets of
> code

That exists. Use eval (or exec).

> and format them in one go.

Include an f-string in the code you eval.

> In other words, I want to be able to do things like that, given an
> *arbitrary* dictionary x and a string s

As I wrote before: An f-string isn't a string. It's a grammatical
construct. So you want to execute Python code which is what eval and
exec do.

hp

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

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Then what about,
>name = input( 'name of the dictionary? ' )
>s = input( 'string? ' )
>dictionary = eval( input( 'dictionary? ' ))
>print( eval( s, {name:dictionary} ))

This works always if the client or user adds the "f" for the
f-string at the start of his string himself. The next program shows
an approach that will not work always, but often.

def evaluate_as_fstring( s ):
if '"""' in s and "'''" in s:
raise Exception( "String contains both \"\"\" and '''!" )
elif '"""' in s: return eval( "f'''" + s + "'''" )
else: return eval( 'f"""' + s + '"""' )

x ={ "y": "z" }

print( evaluate_as_fstring( "-> {x['y']}" ))
print( evaluate_as_fstring( '-> {x["y"]}' ))
print( evaluate_as_fstring( "-> {x['''y''']}" ))
print( evaluate_as_fstring( '-> {x["""y"""]}' ))

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

On Wed, 1 Feb 2023 at 09:14, Rob Cliffe via Python-list
<python-list@python.org> wrote:
> 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.

It's an objectively bad idea. If the OP wants to do it, well, it's a
free world, but that doesn't mean I'm going to sugarcoat it and say
"oh yes, yes, you are totally right to do that".

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

I don't think so, but there might be some value in a dictionary
containing all available variables. It would have the same "don't
depend on writing" caveats that locals() has (or would be specifically
defined as a copy and thus disconnected), so its value would be
limited. And it would probably STILL be imperfect, because perfection
would require that it be a compiler construct, due to the way that
nonlocals are implemented.

>>> class Destructible:
.... def __init__(self, name): self.name = name
.... def __del__(self): print("Deleting", self.name)
....
>>> def func():
.... x = Destructible("x")
.... y = Destructible("y")
.... return lambda: x
....
>>> func()
Deleting y
<function func.<locals>.<lambda> at 0x7ff8c9897ce0>

The compiler is free to dispose of y as soon as func ends, but x has
to be retained for the inner function. So if there were any function
that could return every readable variable, it would have to force both
x and y to be retained; as such, it would have to be a compiler
construct. And given what happened with star imports in functions as
of Python 3, I am highly dubious that such a pessimisation would ever
be implemented.

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

Exactly. This sort of thing is why the OP's idea as written is so bad:
it will cause many unnecessary corner cases, where the much simpler
idea of working it around format_map will actually behave sanely.

So I do not apologize for calling it a bad idea. It is a bad idea.
Lying about it won't change anything and won't help anyone.

ChrisA

Am 31.01.23 um 23:33 schrieb Chris Angelico:

> It's an objectively bad idea. If the OP wants to do it, well, it's a
> free world, but that doesn't mean I'm going to sugarcoat it and say
> "oh yes, yes, you are totally right to do that".

It is pretty baffling how convinced you are of yourself. It would be
amusing if it weren't so toxic.

> Exactly. This sort of thing is why the OP's idea as written is so bad:
> it will cause many unnecessary corner cases, where the much simpler
> idea of working it around format_map will actually behave sanely.

Except, as I have pointed out over and over and over again: your
"solution" does not fit the criteria.

You're calling a lugnut an "objectively bad idea" because obviously in
their right mind would want to use a nail. You're completely ignoring
what my intended solution provides and claiming that your non-solution
solves the problem.

It. Does. Not.

I find it shocking that you are unable to grasp a concept so simple.

> So I do not apologize for calling it a bad idea. It is a bad idea.
> Lying about it won't change anything and won't help anyone.

You know what's objectively worse than a solution that has drawbacks?
One that doesn't solve the issue in *the slightest*, just as *all* of
your suggestions have.

It's quite ridiculous that you critize a solution with such conviction
but are only able to provide completely dysfunctional "alternatives",
utterly broken and without a hint of the requested functionaly. Yet you
claim your solution is "objectively better". This is totally nuts.

I withdraw my earlier statement that you seem to be technically
competent. You have absolutely and utterly no clue what you are talking
about, yet reiterate and advocate "solutions" that are none. This is
pathetic.

Cheers,
Johannes

[re-sending this to both the list and to Chris, as a prior send to the
list only was bounced back]
On 31/01/2023 22:33, Chris Angelico wrote:
>
>> 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?
> I don't think so, but there might be some value in a dictionary
> containing all available variables. It would have the same "don't
> depend on writing" caveats that locals() has (or would be specifically
> defined as a copy and thus disconnected), so its value would be
> limited. And it would probably STILL be imperfect, because perfection
> would require that it be a compiler construct, due to the way that
> nonlocals are implemented.
Does that mean that it is not possible to have a (built-in) function
that would construct and return a dictionary of all available variables
and their values?  If it were possible, it could be useful, and there
would be no impact on Python run-time speed if it were only constructed
on demand.

Best wishes
Rob

Rob Cliffe <rob.cliffe@btinternet.com> writes:
>Does that mean that it is not possible to have a (built-in) function
>that would construct and return a dictionary of all available variables
>and their values?  If it were possible, it could be useful, and there
>would be no impact on Python run-time speed if it were only constructed
>on demand.

Here's a quick attempt to get local and non-local names as a set.
It might only work under some implementations of Python.

main.py

set_class = set

def f():
x = 0
def g():
set = set_class()
for n in g.__qualname__.split( '.' ):
if n != '<locals>':
set = set.union( set_class( eval( n ).__code__.co_varnames ))
print( set )
g()
f()

output

{'n', 'set', 'x'}

On Wed, 8 Feb 2023 at 02:12, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
>
> [re-sending this to both the list and to Chris, as a prior send to the
> list only was bounced back]
> On 31/01/2023 22:33, Chris Angelico wrote:
> >
> >> 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?
> > I don't think so, but there might be some value in a dictionary
> > containing all available variables. It would have the same "don't
> > depend on writing" caveats that locals() has (or would be specifically
> > defined as a copy and thus disconnected), so its value would be
> > limited. And it would probably STILL be imperfect, because perfection
> > would require that it be a compiler construct, due to the way that
> > nonlocals are implemented.
> Does that mean that it is not possible to have a (built-in) function
> that would construct and return a dictionary of all available variables
> and their values? If it were possible, it could be useful, and there
> would be no impact on Python run-time speed if it were only constructed
> on demand.
>

It can't be a built-in function and also be 100% reliable; and if it's
a special compiler construct, its presence in your code would have
semantic impact on all nested functions - even if you never call it:

def func():
x = Obj()
def inner():
if False: get_vars
return inner

x can no longer be disposed of, just in case you call inner and get the vars.

And quite frankly, I don't think this functionality justifies a magic
compiler construct and consequent keyword. But a builtin won't be
reliable.

ChrisA

On Wed, 8 Feb 2023 at 05:30, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>
> Rob Cliffe <rob.cliffe@btinternet.com> writes:
> >Does that mean that it is not possible to have a (built-in) function
> >that would construct and return a dictionary of all available variables
> >and their values? If it were possible, it could be useful, and there
> >would be no impact on Python run-time speed if it were only constructed
> >on demand.
>
> Here's a quick attempt to get local and non-local names as a set.
> It might only work under some implementations of Python.
>
> main.py
>
> set_class = set
>
> def f():
> x = 0
> def g():
> set = set_class()
> for n in g.__qualname__.split( '.' ):
> if n != '<locals>':
> set = set.union( set_class( eval( n ).__code__.co_varnames ))
> print( set )
> g()
> f()
>
> output
>
> {'n', 'set', 'x'}
>

Breaks on wrapped functions. Also, how are you going to get the values
of those variables?

ChrisA