[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

I haven’t given much thought regarding the syntax. The prefix “=“ just popped 
into my mind and I went along with it to use in my examples. The point was that 
f-strings are potentially a good place to implement such thing.

By “elegant", I wasn’t talking about the syntax. It was more about the benefits 
of it being well integrated python construct, which is subject to a parser and 
is a python code by all standards and it fitting in that place sensibly given 
what it is.

Regards,
DG

> On 24 Sep 2023, at 05:15, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> Eric Smith wrote:
>>> Since I wrote that commit: no one is saying it’s impossible or
>>> overly difficult,
> 
>> To be honest it is exactly what was being said.
> 
> Sure ... about an unclearly expressed early version of the proposal,
> that seemed to ask "given an object x, tell me the name of x".  In the
> end, I don't think there was any disagreement that doing that reliably
> is indeed impossible.  But if someone has written that the #nameof
> version of the proposal is impossible to implement, that is not
> representative of what most of us think or have said.
> 
>> What I think is that it would be an elegant feature if it was
>> implemented at python level.
> 
> The postfix '=' flag is elegant by anyone's standard, I think: it
> provides immediately useful, though limited, functionality, with no
> waste, and is automatically fit for purpose because it satisfies DRY.
> And it is mnemonic in the sense that you may have to look it up to
> write it, but once you've learned it, you will recognize it when you
> see it in unfamiliar code because it "looks like" what it produces.
> 
> The proposed prefix '=' flag is much less attractive to me on all
> counts above, except that it's quite mnemonic.
> 
> Steve

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IQKEAWZQYHZECH74BTXBO2T4VF44ZKAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Stephen J. Turnbull]

Dom Grigonis writes:

 > Eric Smith wrote:
 >> Since I wrote that commit: no one is saying it’s impossible or
 >> overly difficult,

 > To be honest it is exactly what was being said.

Sure ... about an unclearly expressed early version of the proposal,
that seemed to ask "given an object x, tell me the name of x".  In the
end, I don't think there was any disagreement that doing that reliably
is indeed impossible.  But if someone has written that the #nameof
version of the proposal is impossible to implement, that is not
representative of what most of us think or have said.

 > What I think is that it would be an elegant feature if it was
 > implemented at python level.

The postfix '=' flag is elegant by anyone's standard, I think: it
provides immediately useful, though limited, functionality, with no
waste, and is automatically fit for purpose because it satisfies DRY.
And it is mnemonic in the sense that you may have to look it up to
write it, but once you've learned it, you will recognize it when you
see it in unfamiliar code because it "looks like" what it produces.

The proposed prefix '=' flag is much less attractive to me on all
counts above, except that it's quite mnemonic.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7MVQ27WLEDWEDKKTSWM4VBWMOENXSIOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Eric V. Smith via Python-ideas]

On Sep 23, 2023, at 5:37 PM, Dom Grigonis  wrote:It seems that my guess was correct. There was a commit, when only the first part was working:https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381aSince I wrote that commit: no one is saying it’s impossible or overly difficult, just that the benefit of having it doesn’t justify the cost of adding it. Costs include implementation, testing, teaching, cognitive load on all readers, etc.I understand that you think it’s worth the cost. Others, including me, do not.Eric So it does seem that it can be done manageably, while all editors with f-string support would benefit instantaneously without extra effort or unnecessary complications such as `typing` library.Regards,DGOn 23 Sep 2023, at 23:55, Dom Grigonis  wrote:the output will have the _expression_ textThis is exactly what I want. If there was an extra check for validity at parser level, it is a plus.You want to produce a name, that is an identifier. Not necessarily, I want the first part of f’{expr=}’.There are outputs:a) `expr=repr(expr)`b) `repr(expr)`why is it a bad idea to have:c) `expr` without `repr(expr)`?This does cover `identifier only` case as well, but is not limited to it.Is it difficult to achieve? Apologies if I am missing something, but if you know the workings of python, could you point me to where f’{expr=}' is parsed and compiled?Obviously I might be wrong, but it is difficult to believe that it is done in such way, that I can have B, A, but not A without B. Would appreciate if you convinced me with some support for your rather strong statements.Regards,DGOn 23 Sep 2023, at 23:18, Tiago Illipronti Girardi  wrote:I think I did something wrong and we are responding to one another instead of the list, please correct this if you can.Let's start with `f'{name=}'`. This is from the docs (the link has the docs for f-strings, so read it):When the equal sign '=' is provided, the output will have the _expression_ text, the '=' and the evaluated value. Spaces after the opening brace '{', within the _expression_ and after the '=' are all retained in the output. By default, the '=' causes the repr() of the _expression_ to be provided, unless there is a format specified. When a format is specified it defaults to the str() of the _expression_ unless a conversion '!r' is declared.That's not what you want. You want to produce a name, that is an identifier. The semantics of name binding are described here. Which means that you cannot infer the name from the value.Python only deals with values, not names. The names are how you refer to the values. That is the semantics. There's no inverse transformation embedded in the language. That's what everyone is trying to communicate to you.If you pay close attention to the execution model there is a link from the name to the object but not the other way around, so you can't get it from the object. That's it. You need to change the whole execution model (that is the interpreter) to get what you  wantEm sáb., 23 de set. de 2023 às 13:16, Dom Grigonis  escreveu:On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi  wrote:The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, with `str` if it is `s`, or with `ascii` if its `a`.With a new format `id` or `i` it would do nothing, but it could signal to an editor that it is an identifier (editors, I believe, already parse the contents of the curly brackets on f-strings).I know the formatting syntax, I wasn’t clear what your point was. I see now that you are referring to new syntax which does nothing apart from signalling the editor.Your suggestion is leaning towards python adapting to the editor, while I would argue that things are simpler and more robust if editors treat code _expression_ as code _expression_ and strings as strings. Making a mess here does seem like too big of a cost for not so profound benefits of what I am proposing.Identifiers are syntactical constructs in python, they only have semantics given a context, and more than one identifier can have the same semantic meaning in a given context, which makes your proposal a no-go from start.Can you elaborate on this?Given f’{expr=}’ syntax already exists, how is this an issue for my proposal?Except if we were to change the whole execution model of the language.Although I am open to be proven wrong. Could you give an explanation why stripping `repr(expr)` part from f’{expr=}’ and leaving expr literal is problematic, given substituting expr literal is already being done?However, for the "change this identifier from this to that" case (which is an editor problem), subclassing `typing.LiteralString` would basically solve the problem:```x = 6print(typing.Id('x') = f'{x}')```Or import Id from typing to save some keystrokes.With an interpreter change to the f-string we could do something like:```print(f'In this context 

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

> Since I wrote that commit: no one is saying it’s impossible or overly 
> difficult,

To be honest it is exactly what was being said.

>  just that the benefit of having it doesn’t justify the cost of adding it.
I can understand that.

> I understand that you think it’s worth the cost.
No, I don’t think that. I wrote here to find that out.

What I think is that it would be an elegant feature if it was implemented at 
python level.

Thanks for reply,
DG

> On 24 Sep 2023, at 02:24, Eric V. Smith  wrote:
> 
> 
> 
>> On Sep 23, 2023, at 5:37 PM, Dom Grigonis  wrote:
>> 
>> It seems that my guess was correct. There was a commit, when only the first 
>> part was working:
>> 
>> https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381a
>>  
>> 
> Since I wrote that commit: no one is saying it’s impossible or overly 
> difficult, just that the benefit of having it doesn’t justify the cost of 
> adding it. Costs include implementation, testing, teaching, cognitive load on 
> all readers, etc.
> 
> I understand that you think it’s worth the cost. Others, including me, do not.
> 
> Eric 
> 
>> 
>> So it does seem that it can be done manageably, while all editors with 
>> f-string support would benefit instantaneously without extra effort or 
>> unnecessary complications such as `typing` library.
>> 
>> Regards,
>> DG
>> 
>>> On 23 Sep 2023, at 23:55, Dom Grigonis >> > wrote:
>>> 
 the output will have the expression text
>>> This is exactly what I want. If there was an extra check for validity at 
>>> parser level, it is a plus.
>>> 
 You want to produce a name, that is an identifier 
 . 
>>> Not necessarily, I want the first part of f’{expr=}’.
>>> There are outputs:
>>> a) `expr=repr(expr)`
>>> b) `repr(expr)`
>>> 
>>> why is it a bad idea to have:
>>> c) `expr` without `repr(expr)`?
>>> 
>>> This does cover `identifier only` case as well, but is not limited to it.
>>> 
>>> Is it difficult to achieve? Apologies if I am missing something, but if you 
>>> know the workings of python, could you point me to where f’{expr=}' is 
>>> parsed and compiled?
>>> 
>>> Obviously I might be wrong, but it is difficult to believe that it is done 
>>> in such way, that I can have B, A, but not A without B. Would appreciate 
>>> if you convinced me with some support for your rather strong statements.
>>> 
>>> Regards,
>>> DG
>>> 
 On 23 Sep 2023, at 23:18, Tiago Illipronti Girardi 
 mailto:tiagoigira...@gmail.com>> wrote:
 
 I think I did something wrong and we are responding to one another instead 
 of the list, please correct this if you can.
 
 Let's start with `f'{name=}'`. This is from the docs 
  (the 
 link has the docs for f-strings, so read it):
 
 When the equal sign '=' is provided, the output will have the expression 
 text, the '=' and the evaluated value. Spaces after the opening brace '{', 
 within the expression and after the '=' are all retained in the output. By 
 default, the '=' causes the repr() 
  of the expression 
 to be provided, unless there is a format specified. When a format is 
 specified it defaults to the str() 
  of the expression 
 unless a conversion '!r' is declared.
 
 That's not what you want. You want to produce a name, that is an 
 identifier 
 . 
 The semantics of name binding are described here 
 .
  Which means that you cannot infer the name from the value.
 Python only deals with values, not names. The names are how you refer to 
 the values. That is the semantics. There's no inverse transformation 
 embedded in the language. That's what everyone is trying to communicate to 
 you.
 If you pay close attention to the execution model 
 
  there is a link from the name to the object but not the other way around, 
 so you can't get it from the object. That's it. You need to change the 
 whole execution model (that is the interpreter) to get what you  want
 
 Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis >>> > escreveu:
 
 
> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi 
> mailto:tiagoigira...@gmail.com>> wrote:
> 
> The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, 
> with `str` if it is `s`, or with `ascii` if its `a`.

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

It seems that my guess was correct. There was a commit, when only the first 
part was working:

https://github.com/python/cpython/pull/13123/commits/67977672360659f203664d23cfc52b5e07e4381a
 


So it does seem that it can be done manageably, while all editors with f-string 
support would benefit instantaneously without extra effort or unnecessary 
complications such as `typing` library.

Regards,
DG

> On 23 Sep 2023, at 23:55, Dom Grigonis  wrote:
> 
>> the output will have the expression text
> This is exactly what I want. If there was an extra check for validity at 
> parser level, it is a plus.
> 
>> You want to produce a name, that is an identifier 
>> . 
> Not necessarily, I want the first part of f’{expr=}’.
> There are outputs:
> a) `expr=repr(expr)`
> b) `repr(expr)`
> 
> why is it a bad idea to have:
> c) `expr` without `repr(expr)`?
> 
> This does cover `identifier only` case as well, but is not limited to it.
> 
> Is it difficult to achieve? Apologies if I am missing something, but if you 
> know the workings of python, could you point me to where f’{expr=}' is parsed 
> and compiled?
> 
> Obviously I might be wrong, but it is difficult to believe that it is done in 
> such way, that I can have B, A, but not A without B. Would appreciate if 
> you convinced me with some support for your rather strong statements.
> 
> Regards,
> DG
> 
>> On 23 Sep 2023, at 23:18, Tiago Illipronti Girardi > > wrote:
>> 
>> I think I did something wrong and we are responding to one another instead 
>> of the list, please correct this if you can.
>> 
>> Let's start with `f'{name=}'`. This is from the docs 
>>  (the 
>> link has the docs for f-strings, so read it):
>> 
>> When the equal sign '=' is provided, the output will have the expression 
>> text, the '=' and the evaluated value. Spaces after the opening brace '{', 
>> within the expression and after the '=' are all retained in the output. By 
>> default, the '=' causes the repr() 
>>  of the expression to 
>> be provided, unless there is a format specified. When a format is specified 
>> it defaults to the str() 
>>  of the expression 
>> unless a conversion '!r' is declared.
>> 
>> That's not what you want. You want to produce a name, that is an identifier 
>> . The 
>> semantics of name binding are described here 
>> .
>>  Which means that you cannot infer the name from the value.
>> Python only deals with values, not names. The names are how you refer to the 
>> values. That is the semantics. There's no inverse transformation embedded in 
>> the language. That's what everyone is trying to communicate to you.
>> If you pay close attention to the execution model 
>>  
>> there is a link from the name to the object but not the other way around, so 
>> you can't get it from the object. That's it. You need to change the whole 
>> execution model (that is the interpreter) to get what you  want
>> 
>> Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis > > escreveu:
>> 
>> 
>>> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi >> > wrote:
>>> 
>>> The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, 
>>> with `str` if it is `s`, or with `ascii` if its `a`.
>>> With a new format `id` or `i` it would do nothing, but it could signal to 
>>> an editor that it is an identifier (editors, I believe, already parse the 
>>> contents of the curly brackets on f-strings).
>> I know the formatting syntax, I wasn’t clear what your point was. I see now 
>> that you are referring to new syntax which does nothing apart from 
>> signalling the editor.
>> 
>> Your suggestion is leaning towards python adapting to the editor, while I 
>> would argue that things are simpler and more robust if editors treat code 
>> expression as code expression and strings as strings. Making a mess here 
>> does seem like too big of a cost for not so profound benefits of what I am 
>> proposing.
>> 
>>> Identifiers are syntactical constructs in python, they only have semantics 
>>> given a context, and more than one identifier can have the same semantic 
>>> meaning in a given context, which makes your proposal a no-go from start.
>> Can you elaborate on this?
>> 
>> Given f’{expr=}’ syntax already exists, how is this an issue for my proposal?
>> 
>>> Except if we were to change the whole execution model of the language.
>> Although 

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

> the output will have the expression text
This is exactly what I want. If there was an extra check for validity at parser 
level, it is a plus.

> You want to produce a name, that is an identifier 
> . 
Not necessarily, I want the first part of f’{expr=}’.
There are outputs:
a) `expr=repr(expr)`
b) `repr(expr)`

why is it a bad idea to have:
c) `expr` without `repr(expr)`?

This does cover `identifier only` case as well, but is not limited to it.

Is it difficult to achieve? Apologies if I am missing something, but if you 
know the workings of python, could you point me to where f’{expr=}' is parsed 
and compiled?

Obviously I might be wrong, but it is difficult to believe that it is done in 
such way, that I can have B, A, but not A without B. Would appreciate if you 
convinced me with some support for your rather strong statements.

Regards,
DG

> On 23 Sep 2023, at 23:18, Tiago Illipronti Girardi  
> wrote:
> 
> I think I did something wrong and we are responding to one another instead of 
> the list, please correct this if you can.
> 
> Let's start with `f'{name=}'`. This is from the docs 
>  (the 
> link has the docs for f-strings, so read it):
> 
> When the equal sign '=' is provided, the output will have the expression 
> text, the '=' and the evaluated value. Spaces after the opening brace '{', 
> within the expression and after the '=' are all retained in the output. By 
> default, the '=' causes the repr() 
>  of the expression to 
> be provided, unless there is a format specified. When a format is specified 
> it defaults to the str() 
>  of the expression 
> unless a conversion '!r' is declared.
> 
> That's not what you want. You want to produce a name, that is an identifier 
> . The 
> semantics of name binding are described here 
> . 
> Which means that you cannot infer the name from the value.
> Python only deals with values, not names. The names are how you refer to the 
> values. That is the semantics. There's no inverse transformation embedded in 
> the language. That's what everyone is trying to communicate to you.
> If you pay close attention to the execution model 
>  
> there is a link from the name to the object but not the other way around, so 
> you can't get it from the object. That's it. You need to change the whole 
> execution model (that is the interpreter) to get what you  want
> 
> Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis  > escreveu:
> 
> 
>> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi > > wrote:
>> 
>> The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, 
>> with `str` if it is `s`, or with `ascii` if its `a`.
>> With a new format `id` or `i` it would do nothing, but it could signal to an 
>> editor that it is an identifier (editors, I believe, already parse the 
>> contents of the curly brackets on f-strings).
> I know the formatting syntax, I wasn’t clear what your point was. I see now 
> that you are referring to new syntax which does nothing apart from signalling 
> the editor.
> 
> Your suggestion is leaning towards python adapting to the editor, while I 
> would argue that things are simpler and more robust if editors treat code 
> expression as code expression and strings as strings. Making a mess here does 
> seem like too big of a cost for not so profound benefits of what I am 
> proposing.
> 
>> Identifiers are syntactical constructs in python, they only have semantics 
>> given a context, and more than one identifier can have the same semantic 
>> meaning in a given context, which makes your proposal a no-go from start.
> Can you elaborate on this?
> 
> Given f’{expr=}’ syntax already exists, how is this an issue for my proposal?
> 
>> Except if we were to change the whole execution model of the language.
> Although I am open to be proven wrong. Could you give an explanation why 
> stripping `repr(expr)` part from f’{expr=}’ and leaving expr literal is 
> problematic, given substituting expr literal is already being done?
> 
> 
>> However, for the "change this identifier from this to that" case (which is 
>> an editor problem), subclassing `typing.LiteralString` would basically solve 
>> the problem:
>> 
>> ```
>> x = 6
>> print(typing.Id('x') = f'{x}')
>> ```
>> 
>> Or import Id from typing to save some keystrokes.
>> 
>> With an interpreter change to the f-string we could do something like:
>> 
>> ```
>> print(f'In this context {x!id} means the horizontal coordinate')
>> ```
>> 
>> or without one 

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

> On 23 Sep 2023, at 16:24, Tiago Illipronti Girardi  
> wrote:
> 
> but:
> 1. There are costs doing it in python. And easy implementation doing it in 
> editor (with the typing support it's almost already done).
What are those costs?

> 2. The f-string functionality is not there right now, but f'{name!id}' would 
> leverage what is there and, with editor support, give the exact `nameof`` 
> support even without further interpret support.
What do you mean by f’{name!id}’ ? I don’t understand your point here.

Are you proposing f’{name!id}’ syntax for it? My whole point is to do this in 
f-strings.

Namely my proposal is f’{=expr}’.

`nameof` function is out of the question - it has no benefits over f-string 
implementation.

> The other use cases you mention are easily dealt with, assuming editor and 
> typing.LiteralString (subclassed) support.
Can you elaborate? I have only basic user knowledge about typing library and 
use it sparsely.

But from what I know, tying this to typing does not seem like a good idea. It 
is very basic functionality and from my POV stands at lower level, while typing 
is optional feature and not everyone uses it or even needs to know it.

DG
—Evaluation of deferred evaluation can be deferred, but not indefinitely —


> Em sáb., 23 de set. de 2023 às 09:51, Dom Grigonis  > escreveu:
>> This is the only use case I can think of.
> Yes, probably most common one, but I have mentioned couple more.
> 
> 1. Keeping dictionary keys in sync with variable name.
> 2. eval / exec statements. Although eval / exec are not recommended in high 
> standard production code, python is widely used in plugins for various apps. 
> E.g. Alfred / Sublime text, where exec/eval can be very useful. Why not have 
> a method to do it a bit more robustly?
> 
> Given python being flexible multipurpose interpreted language, I am sure more 
> use cases would surface.
> 
>> Couldn’t we just subclass typing.LiteralString to typing.Id or something for 
>> this “functionality” and let editing tools deal with it.
> 
> “Could”, but:
> 1. There are benefits doing it in python. And undesired costs of implementing 
> this in editor (see my later e-mails)
> 2. The f-string functionality for it is already there:
> f'{a=}'.rstrip(f'{a}')
> # or a bit better
> f'{a=}'.split('=')[0]
> # = exactly what I am proposing (Except the unneeded evaluation part)
> So if it is already there, why not have it done well given there is little to 
> none overall cost to it? I think cost implementing such things in Editor is 
> much greater.
> 
> Regards,
> DG

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TKB3EVGGSXRBZQ5EXKRX5GCW5NPRVB4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Tiago Illipronti Girardi]

but:
1. There are costs doing it in python. And easy implementation doing it in
editor (with the typing support it's almost already done).
2. The f-string functionality is not there right now, but f'{name!id}'
would leverage what is there and, with editor support, give the exact
`nameof`` support even without further interpret support.

The other use cases you mention are easily dealt with, assuming editor and
typing.LiteralString (subclassed) support.

Em sáb., 23 de set. de 2023 às 09:51, Dom Grigonis 
escreveu:

> This is the only use case I can think of.
>
> Yes, probably most common one, but I have mentioned couple more.
>
> 1. Keeping dictionary keys in sync with variable name.
> 2. eval / exec statements. Although eval / exec are not recommended in
> high standard production code, python is widely used in plugins for various
> apps. E.g. Alfred / Sublime text, where exec/eval can be very useful. Why
> not have a method to do it a bit more robustly?
>
> Given python being flexible multipurpose interpreted language, I am sure
> more use cases would surface.
>
> Couldn’t we just subclass typing.LiteralString to typing.Id or something
> for this “functionality” and let editing tools deal with it.
>
>
> “Could”, but:
> 1. There are benefits doing it in python. And undesired costs of
> implementing this in editor (see my later e-mails)
> 2. The f-string functionality for it is already there:
>
> f'{a=}'.rstrip(f'{a}')# or a bit better
> f'{a=}'.split('=')[0]# = exactly what I am proposing (Except the unneeded 
> evaluation part)
>
> So if it is already there, why not have it done well given there is little
> to none overall cost to it? I think cost implementing such things in Editor
> is much greater.
>
> Regards,
> DG
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A4EFCK6I5Y7IAZF5DHAFVUTJBD6R72RA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

> This is the only use case I can think of.
Yes, probably most common one, but I have mentioned couple more.

1. Keeping dictionary keys in sync with variable name.
2. eval / exec statements. Although eval / exec are not recommended in high 
standard production code, python is widely used in plugins for various apps. 
E.g. Alfred / Sublime text, where exec/eval can be very useful. Why not have a 
method to do it a bit more robustly?

Given python being flexible multipurpose interpreted language, I am sure more 
use cases would surface.

> Couldn’t we just subclass typing.LiteralString to typing.Id or something for 
> this “functionality” and let editing tools deal with it.

“Could”, but:
1. There are benefits doing it in python. And undesired costs of implementing 
this in editor (see my later e-mails)
2. The f-string functionality for it is already there:
f'{a=}'.rstrip(f'{a}')
# or a bit better
f'{a=}'.split('=')[0]
# = exactly what I am proposing (Except the unneeded evaluation part)
So if it is already there, why not have it done well given there is little to 
none overall cost to it? I think cost implementing such things in Editor is 
much greater.

Regards,
DG___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7G5EXX7QBGJB7H3PDNOWXKW2JMPDIJ4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Tiago Illipronti Girardi]

This is the only use case I can think of.
It could be supported by the typing module by subtyping LiteralString and let 
the editor tools do the rest.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TXIAFDSEG5SMNSHH5NH7QXPDY4AISDO4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Pyrous]

>It's really something that needs editor support, not compiler support. As far as the Python interpreter is concerned, this is just a string.>So why not just make it an editor feature?>def nameof(x): return x>print("This " + nameof("thing") + " is:", thing)>As far as I can tell, this isn't a Python feature at all. It's an editor refactoring feature.>ChrisAThis is the only use case I can think of. Couldn’t we just subclass typing.LiteralString to typing.Id or something for this “functionality” and let editing tools deal with it. Also I accidentaly made the windows11 client the app for responding these, can someone help to undo it, thanks. Send from Windows11 client (sorry IT SUCKS) 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HULYOIQBBQKPJWPTWGA666S3B62VMYOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extract variable name from itself

[Dom Grigonis]

> On 23 Sep 2023, at 08:54, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> Simply eval/exec string inputs. I sometimes use of these for ad-hoc
>> callbacks. Would be great if `v` was recognised as a code.
> 
> Looking at the example, do you mean '=' here?  That is, you want to
> add semantics for prefixed '=', meaning "just insert the expression
> string here"?
Correct, it’s the one that I though could make sense, so just keep using it in 
examples now.


>> Code is similar to this: class A:
>>def __init__(self):
>>self.d = {'a': 1, 'b': 2}
>> 
>>def apply(self, smtp):
>>for k, v in self.d.items():
>>if callable(smtp):
>>self.d[k] = smtp(v)
>>elif isinstance(smtp, str):
>>self.d[k] = eval(f'{=v}{smtp}')
> 
> Since f'{=v}' just results in 'v', why isn't
> 
>self.d[k] = eval(f'v{smtp}')
> 
> fine?  Sure, you get the compiler check/refactoring benefit, but as
> you admit, this is a very "ad hack" use case.  I don't think we should
> encourage it in production code.

Agree, this use case is not for production code.

Correct me if I am wrong, but I think `eval` in general should not be 
encouraged in production code.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/N74S6AEKQEXG467DA5CWOW2DAO7KAWN6/
Code of Conduct: http://python.org/psf/codeofconduct/