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

Can you please stop manufacturing consent?

Em dom., 24 de set. de 2023 às 21:06, Dom Grigonis 
escreveu:

> What is your position on this?
>
> Do you think that such thing is worth having?
>
> If yes, do any of the 3 final options seem sensible to you?
>
> > On 25 Sep 2023, at 02:39, Chris Angelico  wrote:
> >
> > On Mon, 25 Sept 2023 at 07:05, Dom Grigonis 
> wrote:
> >> What I meant is that functions in __builtins__ are low level, with
> functionality which is hidden from the user.
> >>
> >
> > What does that even mean?
> >
> > ChrisA
> > ___
> > 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/ERAO66OAI73EO4YYCG3ODI3TPFSKYUEG/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/6ILMQ4PB5W6MAJZZALK47QDFOYYM4M4X/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/XKAS5SGIKYYQ6HDXVHTT5KHL7DWJDO7C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-24 Thread Chris Angelico

On Mon, 25 Sept 2023 at 10:05, Dom Grigonis  wrote:
>
> What is your position on this?
>
> Do you think that such thing is worth having?
>
> If yes, do any of the 3 final options seem sensible to you?
>

My position is that so far, you haven't shown it to be of much value.
Which might be because the idea has no value, but more likely, it's
because I just haven't understood from your posts why this should be
added to the language.

So far, you've shown that this should be an editor feature, but you
haven't convinced me that the language should take any notice of it.

ChrisA
___
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/NFCXP5SILAEJIV7HWS6RDY23WP7H4LVO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

What is your position on this?

Do you think that such thing is worth having?

If yes, do any of the 3 final options seem sensible to you?

> On 25 Sep 2023, at 02:39, Chris Angelico  wrote:
> 
> On Mon, 25 Sept 2023 at 07:05, Dom Grigonis  wrote:
>> What I meant is that functions in __builtins__ are low level, with 
>> functionality which is hidden from the user.
>> 
> 
> What does that even mean?
> 
> ChrisA
> ___
> 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/ERAO66OAI73EO4YYCG3ODI3TPFSKYUEG/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/6ILMQ4PB5W6MAJZZALK47QDFOYYM4M4X/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-24 Thread Chris Angelico

On Mon, 25 Sept 2023 at 07:05, Dom Grigonis  wrote:
> What I meant is that functions in __builtins__ are low level, with 
> functionality which is hidden from the user.
>

What does that even mean?

ChrisA
___
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/ERAO66OAI73EO4YYCG3ODI3TPFSKYUEG/
Code of Conduct: http://python.org/psf/codeofconduct/

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


> 'Esoteric' means something hidden, it is the exact opposite of 'we all know 
> about'
What I meant is that functions in __builtins__ are low level, with 
functionality which is hidden from the user. So my point is that it seems like 
an appropriate place for nameof(). After all, f’{v!}’ applies functions to 
v from builtin namespace: str/repr/ascii.

> Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis  > escreveu:
> 
> 
>> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi > > wrote:
>> 
>> There definitely is a miscommunication:
>> 
>> The 2 first options was me spitballing an alternative against the third.
>> 
>> The not reinventing the wheel remark was me saying that the particular 
>> example that you gave *on that particular message* can already be done.
> I know, I just applied your advice in a different place. :)
> 
>> Also the case 2 f'{name!i}', I suggested as an extension of the current 
>> formatting paradigm, but is also the same as `f{name=}` except that you 
>> don't format the *value*,
>> so I *imagine* (that word pulling more weight than I do at the gym, mind 
>> you) would be trivial to implement. It *needs* editor support regardless.
> So just to double check. You think f’{name!i}’ would be better than simply 
> nameof() builtin?
> 
> I have no problems with either b) or c), but I like c) better. As you said:
> print('In this context, variable', 'name', 'means an esoteric thing that we 
> all know about’)
> 
> Maybe it would be sensible not to couple ‘esoteric` thing with non-esoteric 
> ones and find its place among other unique functionality providing things, 
> such as id, type, exec, etc.
> 
> 
>> While I would be very glad if my opinion is adopted by the community, do not 
>> substitute my opinion for the community's.
>> 
>> Em dom., 24 de set. de 2023 às 12:29, Dom Grigonis > > escreveu:
>> I think the separation is needed between the 2:
>> 
>> a) identifier name
>> b) expression text
>> 
>> I think there is a mix-up between these 2 which causes some confusion (at 
>> least to me). Wanting both made me cling to f-strings as they currently do 
>> b) in ‘postfix=' and a) can be extracted from it.
>> 
>> —
>> 
>> I think having b) will be convenient to extract given/when/if/please 
>> deferred evaluation is implemented:
>> a = `expr`
>> print(a.__expr_text__)  # ‘expr'
>> —
>> 
>> So I think the focus here is a). I think this is what you are having in 
>> mind, while I think about both - thus slight miscommunication.
>> 
>> And for it I currently see 3 options:
>> 1. typing.ID['name']
>>  I think this one is too verbose for what it is. Also requiring an import
>> 2. ‘{name!i}’
>>  This one is sensible (and I think is better than my prefix=)
>> 3. nameof(name)
>>  But I am leaning towards this one.
>>  Pros:
>>  * it is not coupled with either string formatting or typing. 
>>  * C# guys most likely gave some thought into it so the 
>> resulting output can potentially be modelled after it. That is: to either 
>> return identifier name, or the name of the attribute.
>>  * Also, this would be in line with your suggestion of not 
>> reinventing the wheel.
>>  * Finally, there would be no extra editor work.
>>  Cons:
>>  * Extra name in global namespace
>>  * Any thoughts why this isn’t a good option?
>> 
>> Regards,
>> DG
>> 
>>> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi >> > wrote:
>>> 
>>> or
>>> 
>>> print('{a=} and b={a}')
>>> 
>>> This already exists. Kindly stop reinventing the wheel.
>>> 
>>> the thing that does not exist now is:
>>> 
>>> print('In this context, variable', 'name', 'means an esoteric thing that we 
>>> all know about')
>>> 
>>> where `'name'` can be substituted easily (the 'nameof' case) but it could 
>>> be, as an example:
>>> 
>>> print('In this context, variable {name!i} means an esoteric thing that we 
>>> all know about')
>>> 
>>> (my favorite, but interpreter maintenance costs trumps my preferences)
>>> or could be done as:
>>> 
>>> print('In this context, variable', typing.ID['name'], 'means an esoteric 
>>> thing that we all know about')
>>> 
>>> which wouldn't change the interpreter at all, (but would change the stdlib).
>>> 
>>> Either way, the 'nameof'-support needs editor support, because it is an 
>>> *editing* use case, the interpreter just doesn't care.
>>> (It could, but it *can't* do anything without the *editor* responding to it)
>>> 
>>> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis >> > escreveu:
>>> 
>>> 
 On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
 >>> > wrote:
 
 Dom Grigonis writes:
 
>> But it's far from concise
> What could be more concise?
 
 A notation where you don't have to repeat a

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

Appling my specific advice elsewhere is at most cute, in this case it was
offensive, and I doubt it was only to me.

The `'f{name!id}'` syntax is what *I* prefer, but *I* think that
subclassing typing.LiteralString is less disruptive.

'Esoteric' means something hidden, it is the exact opposite of 'we all know
about'

Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis 
escreveu:

>
>
> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi <
> tiagoigira...@gmail.com> wrote:
>
> There definitely is a miscommunication:
>
> The 2 first options was me spitballing an alternative against the third.
>
> The not reinventing the wheel remark was me saying that the particular
> example that you gave *on that particular message* can already be done.
>
> I know, I just applied your advice in a different place. :)
>
> Also the case 2 f'{name!i}', I suggested as an extension of the current
> formatting paradigm, but is also the same as `f{name=}` except that you
> don't format the *value*,
> so I *imagine* (that word pulling more weight than I do at the gym, mind
> you) would be trivial to implement. It *needs* editor support regardless.
>
> So just to double check. You think f’{name!i}’ would be better than simply
> nameof() builtin?
>
> I have no problems with either b) or c), but I like c) better. As you said:
> print('In this context, variable', 'name', 'means an esoteric thing that
> we all know about’)
>
> Maybe it would be sensible not to couple ‘esoteric` thing with
> non-esoteric ones and find its place among other unique functionality
> providing things, such as id, type, exec, etc.
>
>
> While I would be very glad if my opinion is adopted by the community, do
> not substitute my opinion for the community's.
>
>
> Em dom., 24 de set. de 2023 às 12:29, Dom Grigonis 
> escreveu:
>
>> I think the separation is needed between the 2:
>>
>> a) identifier name
>> b) expression text
>>
>> I think there is a mix-up between these 2 which causes some confusion (at
>> least to me). Wanting both made me cling to f-strings as they currently do
>> b) in ‘postfix=' and a) can be extracted from it.
>>
>> —
>>
>> I think having b) will be convenient to extract given/when/if/please
>> deferred evaluation is implemented:
>>
>> a = `expr`print(a.__expr_text__)  *# **‘**expr'*
>>
>> —
>>
>> So I think the focus here is a). I think this is what you are having in
>> mind, while I think about both - thus slight miscommunication.
>>
>> And for it I currently see 3 options:
>> 1. typing.ID['name']
>> I think this one is too verbose for what it is. Also requiring an import
>> 2. ‘{name!i}’
>> This one is sensible (and I think is better than my prefix=)
>> 3. nameof(name)
>> But I am leaning towards this one.
>> Pros:
>> * it is not coupled with either string formatting or typing.
>> * C# guys most likely gave some thought into it so the resulting output
>> can potentially be modelled after it. That is: to either return identifier
>> name, or the name of the attribute.
>> * * **Also, this would be in line with your suggestion of not
>> reinventing the wheel.*
>> * Finally, there would be no extra editor work.
>> Cons:
>> * Extra name in global namespace
>> * Any thoughts why this isn’t a good option?
>>
>> Regards,
>> DG
>>
>> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi <
>> tiagoigira...@gmail.com> wrote:
>>
>> or
>>
>>
>> print('{a=} and b={a}')
>>
>>
>> This already exists. Kindly stop reinventing the wheel.
>>
>> the thing that does not exist now is:
>>
>> print('In this context, variable', 'name', 'means an esoteric thing that we 
>> all know about')
>>
>>
>> where `'name'` can be substituted easily (the 'nameof' case) but it could
>> be, as an example:
>>
>> print('In this context, variable {name!i} means an esoteric thing that we 
>> all know about')
>>
>>
>> (my favorite, but interpreter maintenance costs trumps my preferences)
>> or could be done as:
>>
>> print('In this context, variable', typing.ID['name'], 'means an esoteric 
>> thing that we all know about')
>>
>>
>> which wouldn't change the interpreter at all, (but would change the
>> stdlib).
>>
>> Either way, the 'nameof'-support needs editor support, because it is an
>> *editing* use case, the interpreter just doesn't care.
>> (It could, but it *can't* do anything without the *editor* responding to
>> it)
>>
>> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis <
>> dom.grigo...@gmail.com> escreveu:
>>
>>>
>>>
>>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull <
>>> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>>>
>>> Dom Grigonis writes:
>>>
>>> But it's far from concise
>>>
>>> What could be more concise?
>>>
>>>
>>> A notation where you don't have to repeat a possibly long expression.
>>> For example, numerical positions like regular expressions.  Consider
>>> this possible notation:
>>>
>>>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>>>
>>> Otherwise it isn't great, but it's definitely concise.  In the
>>> simplest case you could

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



> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi  
> wrote:
> 
> There definitely is a miscommunication:
> 
> The 2 first options was me spitballing an alternative against the third.
> 
> The not reinventing the wheel remark was me saying that the particular 
> example that you gave *on that particular message* can already be done.
I know, I just applied your advice in a different place. :)

> Also the case 2 f'{name!i}', I suggested as an extension of the current 
> formatting paradigm, but is also the same as `f{name=}` except that you don't 
> format the *value*,
> so I *imagine* (that word pulling more weight than I do at the gym, mind you) 
> would be trivial to implement. It *needs* editor support regardless.
So just to double check. You think f’{name!i}’ would be better than simply 
nameof() builtin?

I have no problems with either b) or c), but I like c) better. As you said:
print('In this context, variable', 'name', 'means an esoteric thing that we all 
know about’)

Maybe it would be sensible not to couple ‘esoteric` thing with non-esoteric 
ones and find its place among other unique functionality providing things, such 
as id, type, exec, etc.


> While I would be very glad if my opinion is adopted by the community, do not 
> substitute my opinion for the community's.
> 
> Em dom., 24 de set. de 2023 às 12:29, Dom Grigonis  > escreveu:
> I think the separation is needed between the 2:
> 
> a) identifier name
> b) expression text
> 
> I think there is a mix-up between these 2 which causes some confusion (at 
> least to me). Wanting both made me cling to f-strings as they currently do b) 
> in ‘postfix=' and a) can be extracted from it.
> 
> —
> 
> I think having b) will be convenient to extract given/when/if/please deferred 
> evaluation is implemented:
> a = `expr`
> print(a.__expr_text__)  # ‘expr'
> —
> 
> So I think the focus here is a). I think this is what you are having in mind, 
> while I think about both - thus slight miscommunication.
> 
> And for it I currently see 3 options:
> 1. typing.ID['name']
>   I think this one is too verbose for what it is. Also requiring an import
> 2. ‘{name!i}’
>   This one is sensible (and I think is better than my prefix=)
> 3. nameof(name)
>   But I am leaning towards this one.
>   Pros:
>   * it is not coupled with either string formatting or typing. 
>   * C# guys most likely gave some thought into it so the 
> resulting output can potentially be modelled after it. That is: to either 
> return identifier name, or the name of the attribute.
>   * Also, this would be in line with your suggestion of not 
> reinventing the wheel.
>   * Finally, there would be no extra editor work.
>   Cons:
>   * Extra name in global namespace
>   * Any thoughts why this isn’t a good option?
> 
> Regards,
> DG
> 
>> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi > > wrote:
>> 
>> or
>> 
>> print('{a=} and b={a}')
>> 
>> This already exists. Kindly stop reinventing the wheel.
>> 
>> the thing that does not exist now is:
>> 
>> print('In this context, variable', 'name', 'means an esoteric thing that we 
>> all know about')
>> 
>> where `'name'` can be substituted easily (the 'nameof' case) but it could 
>> be, as an example:
>> 
>> print('In this context, variable {name!i} means an esoteric thing that we 
>> all know about')
>> 
>> (my favorite, but interpreter maintenance costs trumps my preferences)
>> or could be done as:
>> 
>> print('In this context, variable', typing.ID['name'], 'means an esoteric 
>> thing that we all know about')
>> 
>> which wouldn't change the interpreter at all, (but would change the stdlib).
>> 
>> Either way, the 'nameof'-support needs editor support, because it is an 
>> *editing* use case, the interpreter just doesn't care.
>> (It could, but it *can't* do anything without the *editor* responding to it)
>> 
>> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis > > escreveu:
>> 
>> 
>>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
>>> >> > wrote:
>>> 
>>> Dom Grigonis writes:
>>> 
> But it's far from concise
 What could be more concise?
>>> 
>>> A notation where you don't have to repeat a possibly long expression.
>>> For example, numerical positions like regular expressions.  Consider
>>> this possible notation:
>>> 
>>>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>>> 
>>> Otherwise it isn't great, but it's definitely concise.  In the
>>> simplest case you could omit the position:
>>> 
>>>f'{=} is {count} at this point in the program.'
>> Hmmm...
>> 
> and violates DRY -- it doesn't solve the problem of the first
> draft typo.
>>> 
 And how is “postfix =“ different?
>>> 
>>> You *can't* use different identifiers for the name and value in
>>>

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

There definitely is a miscommunication:

The 2 first options was me spitballing an alternative against the third.

The not reinventing the wheel remark was me saying that the particular
example that you gave *on that particular message* can already be done.

Also the case 2 f'{name!i}', I suggested as an extension of the current
formatting paradigm, but is also the same as `f{name=}` except that you
don't format the *value*,
so I *imagine* (that word pulling more weight than I do at the gym, mind
you) would be trivial to implement. It *needs* editor support regardless.

While I would be very glad if my opinion is adopted by the community, do
not substitute my opinion for the community's.


Em dom., 24 de set. de 2023 às 12:29, Dom Grigonis 
escreveu:

> I think the separation is needed between the 2:
>
> a) identifier name
> b) expression text
>
> I think there is a mix-up between these 2 which causes some confusion (at
> least to me). Wanting both made me cling to f-strings as they currently do
> b) in ‘postfix=' and a) can be extracted from it.
>
> —
>
> I think having b) will be convenient to extract given/when/if/please
> deferred evaluation is implemented:
>
> a = `expr`print(a.__expr_text__)  *# **‘**expr'*
>
> —
>
> So I think the focus here is a). I think this is what you are having in
> mind, while I think about both - thus slight miscommunication.
>
> And for it I currently see 3 options:
> 1. typing.ID['name']
> I think this one is too verbose for what it is. Also requiring an import
> 2. ‘{name!i}’
> This one is sensible (and I think is better than my prefix=)
> 3. nameof(name)
> But I am leaning towards this one.
> Pros:
> * it is not coupled with either string formatting or typing.
> * C# guys most likely gave some thought into it so the resulting output
> can potentially be modelled after it. That is: to either return identifier
> name, or the name of the attribute.
> * * **Also, this would be in line with your suggestion of not reinventing
> the wheel.*
> * Finally, there would be no extra editor work.
> Cons:
> * Extra name in global namespace
> * Any thoughts why this isn’t a good option?
>
> Regards,
> DG
>
> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi <
> tiagoigira...@gmail.com> wrote:
>
> or
>
>
> print('{a=} and b={a}')
>
>
> This already exists. Kindly stop reinventing the wheel.
>
> the thing that does not exist now is:
>
> print('In this context, variable', 'name', 'means an esoteric thing that we 
> all know about')
>
>
> where `'name'` can be substituted easily (the 'nameof' case) but it could
> be, as an example:
>
> print('In this context, variable {name!i} means an esoteric thing that we all 
> know about')
>
>
> (my favorite, but interpreter maintenance costs trumps my preferences)
> or could be done as:
>
> print('In this context, variable', typing.ID['name'], 'means an esoteric 
> thing that we all know about')
>
>
> which wouldn't change the interpreter at all, (but would change the
> stdlib).
>
> Either way, the 'nameof'-support needs editor support, because it is an
> *editing* use case, the interpreter just doesn't care.
> (It could, but it *can't* do anything without the *editor* responding to
> it)
>
> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis 
> escreveu:
>
>>
>>
>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull <
>> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>>
>> Dom Grigonis writes:
>>
>> But it's far from concise
>>
>> What could be more concise?
>>
>>
>> A notation where you don't have to repeat a possibly long expression.
>> For example, numerical positions like regular expressions.  Consider
>> this possible notation:
>>
>>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>>
>> Otherwise it isn't great, but it's definitely concise.  In the
>> simplest case you could omit the position:
>>
>>f'{=} is {count} at this point in the program.'
>>
>> Hmmm...
>>
>> and violates DRY -- it doesn't solve the problem of the first
>> draft typo.
>>
>>
>> And how is “postfix =“ different?
>>
>>
>> You *can't* use different identifiers for the name and value in
>> "postfix =": the same text is used twice, once as a string and one as
>> an identifier.
>>
>> I see what you mean, but this property is arguably intrinsic to what it
>> is. And is part of f-strings vs explicit formatting property too:
>>
>> variable = 1print(f'{variable=} and b={variable}')# VS
>> msg = 'variable={v} and b={v}'print(msg.format(v=variable))
>>
>> Especially, where msg can be pre-stored and reused. Then maybe not making
>> it f-string only is a better idea. So that one can do:
>>
>> msg = '{a!i}={a} and b={a}'print(msg.format(a=variable))
>>
>>
>>
>>
>>
>>
>
___
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

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

I think the separation is needed between the 2:

a) identifier name
b) expression text

I think there is a mix-up between these 2 which causes some confusion (at least 
to me). Wanting both made me cling to f-strings as they currently do b) in 
‘postfix=' and a) can be extracted from it.

—

I think having b) will be convenient to extract given/when/if/please deferred 
evaluation is implemented:
a = `expr`
print(a.__expr_text__)  # ‘expr'
—

So I think the focus here is a). I think this is what you are having in mind, 
while I think about both - thus slight miscommunication.

And for it I currently see 3 options:
1. typing.ID['name']
I think this one is too verbose for what it is. Also requiring an import
2. ‘{name!i}’
This one is sensible (and I think is better than my prefix=)
3. nameof(name)
But I am leaning towards this one.
Pros:
* it is not coupled with either string formatting or typing. 
* C# guys most likely gave some thought into it so the 
resulting output can potentially be modelled after it. That is: to either 
return identifier name, or the name of the attribute.
* Also, this would be in line with your suggestion of not 
reinventing the wheel.
* Finally, there would be no extra editor work.
Cons:
* Extra name in global namespace
* Any thoughts why this isn’t a good option?

Regards,
DG

> On 24 Sep 2023, at 17:44, Tiago Illipronti Girardi  
> wrote:
> 
> or
> 
> print('{a=} and b={a}')
> 
> This already exists. Kindly stop reinventing the wheel.
> 
> the thing that does not exist now is:
> 
> print('In this context, variable', 'name', 'means an esoteric thing that we 
> all know about')
> 
> where `'name'` can be substituted easily (the 'nameof' case) but it could be, 
> as an example:
> 
> print('In this context, variable {name!i} means an esoteric thing that we all 
> know about')
> 
> (my favorite, but interpreter maintenance costs trumps my preferences)
> or could be done as:
> 
> print('In this context, variable', typing.ID['name'], 'means an esoteric 
> thing that we all know about')
> 
> which wouldn't change the interpreter at all, (but would change the stdlib).
> 
> Either way, the 'nameof'-support needs editor support, because it is an 
> *editing* use case, the interpreter just doesn't care.
> (It could, but it *can't* do anything without the *editor* responding to it)
> 
> Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis  > escreveu:
> 
> 
>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
>> > > wrote:
>> 
>> Dom Grigonis writes:
>> 
 But it's far from concise
>>> What could be more concise?
>> 
>> A notation where you don't have to repeat a possibly long expression.
>> For example, numerical positions like regular expressions.  Consider
>> this possible notation:
>> 
>>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>> 
>> Otherwise it isn't great, but it's definitely concise.  In the
>> simplest case you could omit the position:
>> 
>>f'{=} is {count} at this point in the program.'
> Hmmm...
> 
 and violates DRY -- it doesn't solve the problem of the first
 draft typo.
>> 
>>> And how is “postfix =“ different?
>> 
>> You *can't* use different identifiers for the name and value in
>> "postfix =": the same text is used twice, once as a string and one as
>> an identifier.
> I see what you mean, but this property is arguably intrinsic to what it is. 
> And is part of f-strings vs explicit formatting property too:
> variable = 1
> print(f'{variable=} and b={variable}')
> # VS
> msg = 'variable={v} and b={v}'
> print(msg.format(v=variable))
> Especially, where msg can be pre-stored and reused. Then maybe not making it 
> f-string only is a better idea. So that one can do:
> msg = '{a!i}={a} and b={a}'
> print(msg.format(a=variable))
> 
> 
> 
> 

___
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/SWJ5YHQWHLRW2YKGUDIRYIIXTA43QPMI/
Code of Conduct: http://python.org/psf/codeofconduct/

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



> On 24 Sep 2023, at 17:23, Chris Angelico  wrote:
> 
> On Mon, 25 Sept 2023 at 00:15, Dom Grigonis  wrote:
>> I see what you mean, but this property is arguably intrinsic to what it is. 
>> And is part of f-strings vs explicit formatting property too:
>> 
>> variable = 1
>> print(f'{variable=} and b={variable}')
>> # VS
>> msg = 'variable={v} and b={v}'
>> print(msg.format(v=variable))
>> 
>> Especially, where msg can be pre-stored and reused.
> 
> What do you mean by that? Are you suggesting that there's a massive
> cost in constructing a string literal and thus reusing it with
> .format() is more efficient than an f-string? Because that's, uhh,
> kinda not the point of str.format().
That was in response to it violating DRY. Just pointed out that it is intrinsic 
to the wider scope of how things work in different ways of formatting and for 
it to be completely satisfied, str.format can be used as opposed to f-strings. 
It was about DRY, not efficiency.

> And if that isn't what you mean, what is it? Your posts are often
> distinctly unclear. I get the impression that you think everyone else
> understands your idea.

Apologies. Noted.___
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/23DNNUYD2EYKSZPCHRSF3CTGZYR3XEEK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

or


print('{a=} and b={a}')


This already exists. Kindly stop reinventing the wheel.

the thing that does not exist now is:

print('In this context, variable', 'name', 'means an esoteric thing
that we all know about')


where `'name'` can be substituted easily (the 'nameof' case) but it could
be, as an example:

print('In this context, variable {name!i} means an esoteric thing that
we all know about')


(my favorite, but interpreter maintenance costs trumps my preferences)
or could be done as:

print('In this context, variable', typing.ID['name'], 'means an
esoteric thing that we all know about')


which wouldn't change the interpreter at all, (but would change the stdlib).

Either way, the 'nameof'-support needs editor support, because it is an
*editing* use case, the interpreter just doesn't care.
(It could, but it *can't* do anything without the *editor* responding to it)

Em dom., 24 de set. de 2023 às 11:13, Dom Grigonis 
escreveu:

>
>
> On 24 Sep 2023, at 16:42, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> Dom Grigonis writes:
>
> But it's far from concise
>
> What could be more concise?
>
>
> A notation where you don't have to repeat a possibly long expression.
> For example, numerical positions like regular expressions.  Consider
> this possible notation:
>
>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
>
> Otherwise it isn't great, but it's definitely concise.  In the
> simplest case you could omit the position:
>
>f'{=} is {count} at this point in the program.'
>
> Hmmm...
>
> and violates DRY -- it doesn't solve the problem of the first
> draft typo.
>
>
> And how is “postfix =“ different?
>
>
> You *can't* use different identifiers for the name and value in
> "postfix =": the same text is used twice, once as a string and one as
> an identifier.
>
> I see what you mean, but this property is arguably intrinsic to what it
> is. And is part of f-strings vs explicit formatting property too:
>
> variable = 1print(f'{variable=} and b={variable}')# VS
> msg = 'variable={v} and b={v}'print(msg.format(v=variable))
>
> Especially, where msg can be pre-stored and reused. Then maybe not making
> it f-string only is a better idea. So that one can do:
>
> msg = '{a!i}={a} and b={a}'print(msg.format(a=variable))
>
>
>
>
>
>
___
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/ANC5KTEQND7SLUO2NASDEIYFV3ERJZJE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-24 Thread Chris Angelico

On Mon, 25 Sept 2023 at 00:15, Dom Grigonis  wrote:
> I see what you mean, but this property is arguably intrinsic to what it is. 
> And is part of f-strings vs explicit formatting property too:
>
> variable = 1
> print(f'{variable=} and b={variable}')
> # VS
> msg = 'variable={v} and b={v}'
> print(msg.format(v=variable))
>
> Especially, where msg can be pre-stored and reused.

What do you mean by that? Are you suggesting that there's a massive
cost in constructing a string literal and thus reusing it with
.format() is more efficient than an f-string? Because that's, uhh,
kinda not the point of str.format().

And if that isn't what you mean, what is it? Your posts are often
distinctly unclear. I get the impression that you think everyone else
understands your idea.

ChrisA
___
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/GZPWQBKAGSIQEF5QAFMZ3XYYT34WIPAT/
Code of Conduct: http://python.org/psf/codeofconduct/

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



> On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>>> But it's far from concise
>> What could be more concise?
> 
> A notation where you don't have to repeat a possibly long expression.
> For example, numerical positions like regular expressions.  Consider
> this possible notation:
> 
>f'There are {count} expression{pluralize(count)} denoted by {=0}.'
> 
> Otherwise it isn't great, but it's definitely concise.  In the
> simplest case you could omit the position:
> 
>f'{=} is {count} at this point in the program.'
Hmmm...

>>> and violates DRY -- it doesn't solve the problem of the first
>>> draft typo.
> 
>> And how is “postfix =“ different?
> 
> You *can't* use different identifiers for the name and value in
> "postfix =": the same text is used twice, once as a string and one as
> an identifier.
I see what you mean, but this property is arguably intrinsic to what it is. And 
is part of f-strings vs explicit formatting property too:
variable = 1
print(f'{variable=} and b={variable}')
# VS
msg = 'variable={v} and b={v}'
print(msg.format(v=variable))
Especially, where msg can be pre-stored and reused. Then maybe not making it 
f-string only is a better idea. So that one can do:
msg = '{a!i}={a} and b={a}'
print(msg.format(a=variable))




___
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/VV7FFVBVTXCAOI6OQVHN3DZIIM5RVPLT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

The problem is that `f'{exp,format}'` is the current 'status
quo'/'zeitgeist'
You are trying to invert it. It looks wrong. (That's taste, not technical,
if you don't think it is a problem, it isn't a problem for *you*)

The technical: `f'{=name}'` doesn't tell what you're trying to do if you
don't already know what it would do.

And to be clear, the "nameof" part of the proposal I strongly support, I'm
just debating the easiest (an prettiest, how *I* see it) way to get it

Em dom., 24 de set. de 2023 às 10:01, Dom Grigonis 
escreveu:

>
> > But it's far from concise
> What could be more concise?
>
> > and
> > violates DRY -- it doesn't solve the problem of the first draft typo.
> And how is “postfix =“ different?
>
> > I don't see it as elegant the way "postfix =" is.
> Agreed.
>
> 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/UR2J6SEAGKLAM2AIXO3746MGMZUH5ZRK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-24 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > > But it's far from concise
 > What could be more concise?

A notation where you don't have to repeat a possibly long expression.
For example, numerical positions like regular expressions.  Consider
this possible notation:

f'There are {count} expression{pluralize(count)} denoted by {=0}.'

Otherwise it isn't great, but it's definitely concise.  In the
simplest case you could omit the position:

f'{=} is {count} at this point in the program.'

 > > and violates DRY -- it doesn't solve the problem of the first
 > > draft typo.

 > And how is “postfix =“ different?

You *can't* use different identifiers for the name and value in
"postfix =": the same text is used twice, once as a string and one as
an identifier.
___
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/HNARI3L4PXNTJFGZD5AHTBG2RBLIC5OD/
Code of Conduct: http://python.org/psf/codeofconduct/

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


> But it's far from concise
What could be more concise?

> and
> violates DRY -- it doesn't solve the problem of the first draft typo.
And how is “postfix =“ different?

> I don't see it as elegant the way "postfix =" is.
Agreed.

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/MJ6FVYOKOLGGHSHAEOGCVNCGSRY42M44/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-24 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > By “elegant", I wasn’t talking about the syntax.

Neither was I, except in the comment about "mnemonic".  I use "postfix
=" and "prefix =" because I don't know of better names that indicate
the semantics of the feature.

Semantically, "prefix =" is a reasonable solution to the problem --
assuming you consider it a problem.  But it's far from concise and
violates DRY -- it doesn't solve the problem of the first draft typo.
I don't see it as elegant the way "postfix =" is.
___
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/NB66RQQID7HKB5NOG6BRGQMZCPDHBQ7P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

2023-09-23 Thread 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

2023-09-23 Thread 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

> 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

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

> 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


> 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

2023-09-23 Thread 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

> 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

2023-09-23 Thread 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

2023-09-23 Thread 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



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

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

2023-09-22 Thread Stephen J. Turnbull

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

 > 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.
___
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/PEVTGJOPRWP5SLBLK4UZHISD3EGTRR7K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-22 Thread Dom Grigonis

Just want to add to this as I encountered a case, where I think f-string would 
be sensible to use. Third potential use case after logging & dictionary key 
synchronisation with variables names.

Simply eval/exec string inputs. I sometimes use of these for ad-hoc callbacks. 
Would be great if `v` was recognised as a code. 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}')

a = A()
print(a.d)# {'a': 1, 'b': 2}
a.apply(lambda x: x * 2)
print(a.d)# {'a': 2, 'b': 4}
a.apply('* 2')
print(a.d)# {'a': 4, 'b': 8}
Regards,
DG


> On 16 Sep 2023, at 20:43, Dom Grigonis  wrote:
> 
> Agree, all good points.
> f'{=expr}'.split('.')[-1]
> Does take care of all cases and `nameof` has no additional use over it.
> 
> It seems that `nameof` is out of question.
> 
> DG
> 
>> On 16 Sep 2023, at 19:50, Stephen J. Turnbull 
>> > > wrote:
>> 
>> Dom Grigonis writes:
>> 
>>> print(f'{=A.a}')# 'A.a'
>>> print(nameof(A.a))  # 'a'
>> 
>> I see that's the C# semantics, but it's not obvious to me why the
>> ambiguity introduced is worth emulating.  The important aspect of the
>> proposed 'nameof' operator is that its argument can be validated by
>> the compiler and unambiguously recognized by refactoring tools.  But
>> once it's a string, it loses those advantages.  Why not be unambiguous?
>> 
>> I don't think that the tricks recommended (ie, typeof) to retrieve a
>> fully-qualified name in C# would be unambiguous in Python.
>> 
>> Also, Python's f-string '=' operator handles a broad variety of
>> expressions, not just attribute references.  This has been useful to
>> me more often than bare names and attribute references.
>> 
>>> Both [member name and full reference] seem useful to me.
>> 
>> What am I missing?  When would you want the member name only but
>> "nameof().split('.')[-1]" would not do?
>> 
>> Also, are there use cases for the proposed nameof other than a more
>> flexible f-string '='?  Ie, where only the str is wanted, not the
>> str-ified object?  That clearly doesn't apply to the refactoring
>> application, though, unless you're communicating local names to
>> nonlocal computations or using eval, both of which seem like really
>> dubious practices to me.
>> 
>>> So the functionality is bound to an editor and anyone using another
>>> editor would just see a weird string?
>> 
>> No, they'd see an ordinary string.  Editors would use heuristics to
>> recognize strings like f"the value of expression is {expression}".  I
>> do stuff like this in Emacs all the time ad hoc, Chris is just
>> suggesting that some editors/IDEs would provide a more powerful and
>> accurate facility.  I see while I was composing this Bruce Leban came
>> up with a very plausible convention, too.
>> 
>>> Use cases are mostly bug-free refactoring,
>> 
>> But the refactoring is very "meta" in the sense that you're creating a
>> string that refers to the name of an object.  You either need an
>> external agent or computation which would be confused if the name were
>> incorrect, or to be using eval() for this to be an actual refactoring.
>> All of this seems very "code smelly" to me.  If you're refactoring
>> this automatically, you're doing it wrong. ;-)
>> 
>> I don't see any use case that f-string '=' doesn't satisfy well enough
>> to make a new builtin pseudo-function[1] justifiable.
>> 
>>> E.g. would it be faster than `Class.__name__`?
>> 
>> You're working with strings expressing code.  If it's about speed,
>> there's got to be a better way.
>> 
>> 
>> 
>> Footnotes: 
>> [1]  In C#, 'nameof' is first looked up as a function reference, and
>> if found that is called.  Otherwise the compiler macro is used.
>> 
> 

___
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/DSDPXKMPHAILIGWU5S45YXPPHH5KQRIH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-18 Thread Dom Grigonis

Thank you Jonathan,

This is indeed helpful, I have completely forgotten about these.

However, in my case, defaults are not callable defaults, but rather default 
values preset at a higher level object and it has little to do with function 
defaults.

Although, I think it is possible to reshape the problem to use the mechanism 
you have provided. For example:

class Node:
def __init__(self, a=1):
self.a = a

class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_cls = Node
self.node_cls.__init__.__defaults__ = (a,)
# The issue, however is that it modifies the constructor from outside
# And it changes the Node class for the whole Runtime
# copy, deepcopy do not work here either
# Construct the node class programatically by inheritance leads to the 
same issue:
# self.node_cls = type('Node2', (Node,), {})
# self.node_cls.__init__.__defaults__ = (a,)
self.nodes = list()

def new_node(self, *args, **kwds):
node = self.node_cls(*args, **kwds)
self.nodes.append(node)
return node

c = Container(a=2)
print(c.new_node().a)   # 2
print(c.new_node(3).a)  # 3
print(Node().a) # 2
If you could provide an example, which solves the same issue that I have 
presented in a more elegant manner than simple dictionary storage, I would 
appreciate it.

Kind regards,
DG


> On 18 Sep 2023, at 17:24, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> In your original post you used your proposed addition to write code that 
> provides a way of handling defaults different from the standard mechanism, 
> and perhaps in your opinion better.
> 
> The following example tells us something about defaults mechanism already 
> provided by Python:
> 
> >>> def f(a, b=1, c=2): return a, b, c
> ... 
> >>> f(0)
> (0, 1, 2)
> >>> f.__defaults__
> (1, 2)
> >>> f.__defaults__ = (0, 1, 2)
> >>> f()
> (0, 1, 2)
> >>> f.__defaults__ = (2, 1, 0)
> >>> f()
> (2, 1, 0)
> 
> I am suspicious of your example in your original post because it does not 
> explicitly consider the possibilities already provided by Python for changing 
> default values on the fly.
> 
> I hope this helps.
> 
> Jonathan

___
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/MUGEZV47DCD7BO43JZ7AFFAGGKETWM5D/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-18 Thread Jonathan Fine

Hi Dom

In your original post you used your proposed addition to write code that
provides a way of handling defaults different from the standard mechanism,
and perhaps in your opinion better.

The following example tells us something about defaults mechanism already
provided by Python:

>>> def f(a, b=1, c=2): return a, b, c
...
>>> f(0)
(0, 1, 2)
>>> f.__defaults__
(1, 2)
>>> f.__defaults__ = (0, 1, 2)
>>> f()
(0, 1, 2)
>>> f.__defaults__ = (2, 1, 0)
>>> f()
(2, 1, 0)

I am suspicious of your example in your original post because it does not
explicitly consider the possibilities already provided by Python for
changing default values on the fly.

I hope this helps.

Jonathan
___
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/VAFITY5GD2JF7TCDDH356226ZUMP4IJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-17 Thread Dom Grigonis

Thank you Jonathan,

Could you please elaborate on your suspicion, that my proposed addition will 
make bad code easier to write?

It would be nice if you provided example, where there is a pattern using my 
proposed addition, where similar badness of code cant be achieved using already 
existing python constructs.

Also, some explanation why would you deem it as bad code would be helpful.

Regards,
Dominykas

Now is better than never.
Although never is often better than *right* now.
While deferred evaluation is the happy midst of this temporal confusion.


> On 17 Sep 2023, at 11:47, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> To support your proposal you provided an example. Well done for providing 
> evidence to support your idea. Doing that makes the discussion more 
> productive.
> 
> I'm going to use the words 'good' and 'bad', but with two provisos. The first 
> is that they are judgemental, and often judgement is little more than 
> personal opinion presented in an objective language. The second is that 
> 'good' and 'bad' depend on context. The usual C-Python is not good at writing 
> code where high performance is critical (but is fairly good at linking to 
> external libraries that do provide high performance). However, often 
> high-performance is of no importance when writing a prototype. For prototypes 
> the forces are quite different than for production.
> 
> With these provisos, a major purpose of a programming language is to make 
> good code easier to write, and bad code harder to write. Hence the importance 
> of you providing a coding example to support your idea. And also my request 
> that you provide more information about the example code you kindly provided.
> 
> Based on your example, I suspect that your proposed addition will make bad 
> code easier to write. However, we don't need to discuss that now. I suggest 
> that for your proposal to gain support an example of how it makes good code 
> easier to write would be helpful. And also if you wish an example of how it 
> makes bad code harder to write.
> 
> Please note that my use of 'good' and 'bad' are subject to the provisos 
> mentioned earlier.
> 
> I hope this helps.
> 
> Jonathan
> 
> 
> 
> 
> 

___
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/A4EG7HT2SNUJ5UF2LZ3T2P2L6AUH6IV7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-17 Thread Jonathan Fine

Hi Dom

To support your proposal you provided an example. Well done for providing
evidence to support your idea. Doing that makes the discussion more
productive.

I'm going to use the words 'good' and 'bad', but with two provisos. The
first is that they are judgemental, and often judgement is little more than
personal opinion presented in an objective language. The second is that
'good' and 'bad' depend on context. The usual C-Python is not good at
writing code where high performance is critical (but is fairly good at
linking to external libraries that do provide high performance). However,
often high-performance is of no importance when writing a prototype. For
prototypes the forces are quite different than for production.

With these provisos, a major purpose of a programming language is to make
good code easier to write, and bad code harder to write. Hence the
importance of you providing a coding example to support your idea. And also
my request that you provide more information about the example code you
kindly provided.

Based on your example, I suspect that your proposed addition will make bad
code easier to write. However, we don't need to discuss that now. I suggest
that for your proposal to gain support an example of how it makes good code
easier to write would be helpful. And also if you wish an example of how it
makes bad code harder to write.

Please note that my use of 'good' and 'bad' are subject to the provisos
mentioned earlier.

I hope this helps.

Jonathan
___
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/UOXPJVTGSF2FAUBALMHKCWYWNGT73QV4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Hi Jonathan,

I wasn’t writing anything specialised on handling of defaults. My initial 
example pretty much covers it.

What defaults handler of python are you talking about?

This proposal is more about convenient refactoring and keeping things nicely 
synchronised where variable name and string value are preferred to be kept in 
sync. The default handling is just one such case. It can also be useful in 
logging.

I can make my initial example a bit more clear and closer to what actually 
happened:

class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_defaults[f'{=a}'] = a
self.nodes = list()

def new_node(self, a=None):
if a is None:
a = self.node_defaults.get(f'{=a}')
node = Node(a)
self.nodes.append(a)
return node

class Node:
def __init__(self, a):
self.a = a
Currently, I just store keys as close to the object that finally uses the value 
as possible. So to achieve similar overall effect. And I am not saying that the 
above is better than below. IMO, it all depends on individual case. My point is 
that it might be nice to have. And I think the reasoning for such thing goes 
more along the lines of convenience, rather than if similar result can be 
achieved in different ways.
class Container:
def __init__(self, a):
self.node_defaults = dict()
self.node_defaults[Node.K_A] = a
self.nodes = list()

def new_node(self, a=None):
if a is None:
a = self.node_defaults.get(Node.K_A)
node = Node(a)
self.nodes.append(a)
return node

class Node:
K_A = 'a'

def __init__(self, a):
self.a = a

Regards,
DG

—What can not be solved by force, can be solved by deferred evaluation —

> On 16 Sep 2023, at 21:27, Jonathan Fine  wrote:
> 
> Hi Dom
> 
> In your original post you said you're writing some code to improve handling 
> of defaults (perhaps only in some situations). You also said that the feature 
> you're suggesting would make your improved default handler easier to write.
> 
> Python already handles default values at least fairly well in many 
> situations. Please would you provide at least one example of how your 
> proposed default handler would be better than that already provided by Python.
> 
> Please don't worry about the implementation. Please focus on the syntax and 
> semantics and comparison with what Python does.
> 
> I will value your response to my request more highly if it shows that you 
> have a clear understanding of Python's present behaviour. I'd also welcome 
> any example you provide of weaknesses in Python's present behaviour.
> 
> I hope this helps.
> 
> Jonathan

___
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/JNDAOK6EPYAUJZA5DDG6R2S3AAKOY62J/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Jonathan Fine

Hi Dom

In your original post you said you're writing some code to improve handling
of defaults (perhaps only in some situations). You also said that the
feature you're suggesting would make your improved default handler easier
to write.

Python already handles default values at least fairly well in many
situations. Please would you provide at least one example of how your
proposed default handler would be better than that already provided by
Python.

Please don't worry about the implementation. Please focus on the syntax and
semantics and comparison with what Python does.

I will value your response to my request more highly if it shows that you
have a clear understanding of Python's present behaviour. I'd also welcome
any example you provide of weaknesses in Python's present behaviour.

I hope this helps.

Jonathan
___
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/DVRIWWCTLMMZI74LQAXMPJLO2S3FZJC3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Agree, all good points.
f'{=expr}'.split('.')[-1]
Does take care of all cases and `nameof` has no additional use over it.

It seems that `nameof` is out of question.

DG

> On 16 Sep 2023, at 19:50, Stephen J. Turnbull 
>  wrote:
> 
> Dom Grigonis writes:
> 
>> print(f'{=A.a}')# 'A.a'
>> print(nameof(A.a))  # 'a'
> 
> I see that's the C# semantics, but it's not obvious to me why the
> ambiguity introduced is worth emulating.  The important aspect of the
> proposed 'nameof' operator is that its argument can be validated by
> the compiler and unambiguously recognized by refactoring tools.  But
> once it's a string, it loses those advantages.  Why not be unambiguous?
> 
> I don't think that the tricks recommended (ie, typeof) to retrieve a
> fully-qualified name in C# would be unambiguous in Python.
> 
> Also, Python's f-string '=' operator handles a broad variety of
> expressions, not just attribute references.  This has been useful to
> me more often than bare names and attribute references.
> 
>> Both [member name and full reference] seem useful to me.
> 
> What am I missing?  When would you want the member name only but
> "nameof().split('.')[-1]" would not do?
> 
> Also, are there use cases for the proposed nameof other than a more
> flexible f-string '='?  Ie, where only the str is wanted, not the
> str-ified object?  That clearly doesn't apply to the refactoring
> application, though, unless you're communicating local names to
> nonlocal computations or using eval, both of which seem like really
> dubious practices to me.
> 
>> So the functionality is bound to an editor and anyone using another
>> editor would just see a weird string?
> 
> No, they'd see an ordinary string.  Editors would use heuristics to
> recognize strings like f"the value of expression is {expression}".  I
> do stuff like this in Emacs all the time ad hoc, Chris is just
> suggesting that some editors/IDEs would provide a more powerful and
> accurate facility.  I see while I was composing this Bruce Leban came
> up with a very plausible convention, too.
> 
>> Use cases are mostly bug-free refactoring,
> 
> But the refactoring is very "meta" in the sense that you're creating a
> string that refers to the name of an object.  You either need an
> external agent or computation which would be confused if the name were
> incorrect, or to be using eval() for this to be an actual refactoring.
> All of this seems very "code smelly" to me.  If you're refactoring
> this automatically, you're doing it wrong. ;-)
> 
> I don't see any use case that f-string '=' doesn't satisfy well enough
> to make a new builtin pseudo-function[1] justifiable.
> 
>> E.g. would it be faster than `Class.__name__`?
> 
> You're working with strings expressing code.  If it's about speed,
> there's got to be a better way.
> 
> 
> 
> Footnotes: 
> [1]  In C#, 'nameof' is first looked up as a function reference, and
> if found that is called.  Otherwise the compiler macro is used.
> 

___
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/K4QOZTA7B6VK324UHSSRXNF262VTOLLN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Stephen J. Turnbull

Dom Grigonis writes:

 > print(f'{=A.a}')# 'A.a'
 > print(nameof(A.a))  # 'a'

I see that's the C# semantics, but it's not obvious to me why the
ambiguity introduced is worth emulating.  The important aspect of the
proposed 'nameof' operator is that its argument can be validated by
the compiler and unambiguously recognized by refactoring tools.  But
once it's a string, it loses those advantages.  Why not be unambiguous?

I don't think that the tricks recommended (ie, typeof) to retrieve a
fully-qualified name in C# would be unambiguous in Python.

Also, Python's f-string '=' operator handles a broad variety of
expressions, not just attribute references.  This has been useful to
me more often than bare names and attribute references.

 > Both [member name and full reference] seem useful to me.

What am I missing?  When would you want the member name only but
"nameof().split('.')[-1]" would not do?

Also, are there use cases for the proposed nameof other than a more
flexible f-string '='?  Ie, where only the str is wanted, not the
str-ified object?  That clearly doesn't apply to the refactoring
application, though, unless you're communicating local names to
nonlocal computations or using eval, both of which seem like really
dubious practices to me.

 > So the functionality is bound to an editor and anyone using another
 > editor would just see a weird string?

No, they'd see an ordinary string.  Editors would use heuristics to
recognize strings like f"the value of expression is {expression}".  I
do stuff like this in Emacs all the time ad hoc, Chris is just
suggesting that some editors/IDEs would provide a more powerful and
accurate facility.  I see while I was composing this Bruce Leban came
up with a very plausible convention, too.

 > Use cases are mostly bug-free refactoring,

But the refactoring is very "meta" in the sense that you're creating a
string that refers to the name of an object.  You either need an
external agent or computation which would be confused if the name were
incorrect, or to be using eval() for this to be an actual refactoring.
All of this seems very "code smelly" to me.  If you're refactoring
this automatically, you're doing it wrong. ;-)

I don't see any use case that f-string '=' doesn't satisfy well enough
to make a new builtin pseudo-function[1] justifiable.

 > E.g. would it be faster than `Class.__name__`?

You're working with strings expressing code.  If it's about speed,
there's got to be a better way.

Footnotes: 
[1]  In C#, 'nameof' is first looked up as a function reference, and
if found that is called.  Otherwise the compiler macro is used.

___
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/XC7QRRJN7DSF2AKDCMZWANQVOPJM65QI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

If it is done at a tool level, it is not a robust solution. The fact that it 
can be done in a tool doesn’t mean that it is the optimal solution. Having it 
done at python level could be a simpler solution and provide benefits to all of 
the tools, without needing for editor logic to deviate from python logic. Also, 
it eliminates inconsistencies and coding styles which would arise if each 
editor was to implement its own method.

Besides, editor tool implementation doesn’t offer all of the benefits, which on 
top of the refactoring benefits offer:
a) validity check in both f-strings and nameof().
b) nameof(‘a.b’) = ‘b’, which is not a straight forward equality.

Regarding f-strings.
I think the fact that it is already being done in python justifies its validity:
a = 1
print(f'{a=}')
and everybody is happy using it instead of:
print(f'a={a}')
If the argument that this sort of thing should be done in editor is deemed to 
be a valid one, then the `f’{expr=}’` expression was a mistake. However, the 
way I see it, it is very useful addition and I do use it a fair bit.

What I am proposing is nothing new, but rather a small part of what is already 
there, arguably bringing it closer to modular completeness:
print(f'{a}')
print(f'{a=}')
print(f'{=a}')
It’s the same as “I can draw square, square and circle, but I cant draw a 
circle without a square”.

It seems like a non-invasive addition, not causing any problems, not cluttering 
namespaces and how I see it, has just the right place for it and its syntax 
space is very unlikely to be used for anything else.

I do not see a big cost in either implementation or maintenance. The question 
is whether benefits justify that cost.

DG

> On 16 Sep 2023, at 18:37, Bruce Leban  wrote:
> 
> If the goal is to create a syntax that allows tools to recognize names in 
> strings, there is a simple solution which requires tool changes only, for 
> example:
> 
> raise Exception('The field ' + ((('size'))) + ' must be a positive integer in 
> ' + ((('Sample.widget'
> 
> Python already treats triple parenthesized strings properly and all you need 
> to do is modify tools to recognize that syntax. It's even backwards 
> compatible, visually striking, and doesn't prevent compile-time string 
> folding.
> 
> --- Bruce
> 
> ___
> 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/OXEOPXY7BCFB4P7XKEAM3UN5XU6RIHJP/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/TRRMMUCYRJVAORM4RFDJFXGKP53ZVQ47/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Bruce Leban

If the goal is to create a syntax that allows tools to recognize names in
strings, there is a simple solution which requires tool changes only, for
example:

raise Exception('The field ' + ((('size'))) + ' must be a positive integer
in ' + ((('Sample.widget'

Python already treats triple parenthesized strings properly and all you
need to do is modify tools to recognize that syntax. It's even backwards
compatible, visually striking, and doesn't prevent compile-time string
folding.

--- Bruce

>
>
___
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/OXEOPXY7BCFB4P7XKEAM3UN5XU6RIHJP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Chris Angelico

On Sat, 16 Sept 2023 at 19:48, Jeff Allen  wrote:
> It needs language (parser) support because it does what you identified early 
> on: "take whatever is given and put it in quotes", where "whatever is given" 
> is the text of the expression only available at run-time.
>

I didn't say "and put it in quotes". I said "return the text string unchanged".

This is, fundamentally, a problem of an editing tool. Teach the tool
that a string literal inside nameof() should be parsed for variables.
This is no harder than taking the program source and parsing it for
variables - in fact, it's the exact same thing, just done a second
time.

I have done exactly this sort of parsing, using the Python ast module.
It's not difficult.

ChrisA
___
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/IRT4UNFBKPEP6U2PENVGQEAQQQ3WSBW2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Jeff Allen


On 16/09/2023 11:33, Dom Grigonis wrote:


It works already with existing tools that will treat "nameof(a+b)" as 
a function call, which it is syntactically but not semantically, so 
renaming b to c will now produce the string "a+c". I think my IDE 
does offer to do this with variable names in strings and comments, 
but it produces so many false hits I don't enjoy using the feature.


So the functionality is bound to an editor and anyone using another 
editor would just see a weird string?

After several similar editor features things could get very confusing.

No, the opposite. By "works now", I meant to say that if a nameof() 
pseudo-function were added to the Python language, existing tools would 
not have to change, because they would treat it as a call. This does 
scratch an itch (in renaming) by removing the need to guess or ask the 
human whether a given string is a variable name.


I'm not convinced this feature is widely useful.


So what is the general procedure for determining it?


1. Compelling use cases here or (better) on the Dicourse counterpart
   .
2. Community and core dev acclamation as a Good Thing.
3. Willigness to implement and maintain.

--

Jeff Allen
___
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/LUDUIZB7VEYPUQWIT2YGYV3ECKMZ2V4J/
Code of Conduct: http://python.org/psf/codeofconduct/

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



Yes, it seems it does have scope beyond editor in both cases.
class A: a = 1

print(f'{=A.a}')# 'A.a'
print(nameof(A.a))  # 'a'
In f-string case, if to be consistent with current f-string functionality, 
expression would be checked for a validity and that reference is in scope and 
available. Essentially, everything that `f{A.a=}` does now, except actual 
evaluation.

In `nameof` case, it only prints the name of the last attribute and drops the 
tail. It is also naturally checked for validity.

Both seem useful to me.

> It works already with existing tools that will treat "nameof(a+b)" as a 
> function call, which it is syntactically but not semantically, so renaming b 
> to c will now produce the string "a+c". I think my IDE does offer to do this 
> with variable names in strings and comments, but it produces so many false 
> hits I don't enjoy using the feature.

So the functionality is bound to an editor and anyone using another editor 
would just see a weird string?
After several similar editor features things could get very confusing.

> I'm not convinced this feature is widely useful.
> 

So what is the general procedure for determining it?


On a side note,
I have stumbled on this stack thread:
https://stackoverflow.com/questions/31695900/what-is-the-purpose-of-nameof 

Use cases are mostly bug-free refactoring, but some are using it for resource 
check at compie time. Also, certain cases C# offer speed benefits. E.g. would 
it be faster than `Class.__name__`?

DG

> On 16 Sep 2023, at 12:44, Jeff Allen  wrote:
> 
> On 16/09/2023 01:14, Chris Angelico wrote:
>> But if that tool can be taught that nameof indicates a variable name,
>> then it can rename inside it just like it would rename anything else.
>> Your problem here is a limitation of the variable renaming tool. I'm
>> suggesting a solution to that problem. This is not a language problem,
>> it's an editor problem, so it needs an editor solution.
> It needs language (parser) support because it does what you identified early 
> on: "take whatever is given and put it in quotes", where "whatever is given" 
> is the text of the expression only available at run-time. (Actually, I can 
> think of something complicated one might possibly do with the text produced 
> in exceptions, but please don't.)
> Taking an example from my REPL just now (it happens that r2 is the AST of an 
> Expression), you could simulate nameof with f-strings:
> 
> >>> f"{r2.body.op.test=}"
> 'r2.body.op.test=42'
> >>> f"{r2.body.op.test=}".split('=')[0]
> 'r2.body.op.test'
> 
> This also evaluates the expression, encodes the result as text then discards 
> it, which is undesirable. The point is that renaming r2, or the fields of a 
> BinOp (if it were project-local, not a stdlib object) would cause the string 
> to change in most existing IDEs.
> Attempts to guess the name from the expression at runtime are futile and a 
> red herring. Trying to describe the desired semantics that way leads to 
> nonsensical ideas, I agree.
> 


> -- 
> 
> Jeff Allen
> ___
> 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/RQISFW5UV2EW6ZB3ZKUDNV2R45MWIH3O/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/SWM5ZL6X3TQV24OAPQOH3GI4UNPV2AJL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-16 Thread Jeff Allen

On 16/09/2023 01:14, Chris Angelico wrote:

But if that tool can be taught that nameof indicates a variable name,
then it can rename inside it just like it would rename anything else.
It works already with existing tools that will treat "nameof(a+b)" as a
function call, which it is syntactically but not semantically, so
renaming b to c will now produce the string "a+c". I think my IDE does
offer to do this with variable names in strings and comments, but it
produces so many false hits I don't enjoy using the feature.

Your problem here is a limitation of the variable renaming tool. I'm
suggesting a solution to that problem. This is not a language problem,
it's an editor problem, so it needs an editor solution.
It needs language (parser) support because it does what you identified
early on: "take whatever is given and put it in quotes", where "whatever
is given" is the text of the expression only available at run-time.
(Actually, I can think of something complicated one might possibly do
with the text produced in exceptions, but please don't.)

Taking an example from my REPL just now (it happens that r2 is the AST
of an Expression), you could simulate nameof with f-strings:

>>> f"{r2.body.op.test=}"
'r2.body.op.test=42'
>>> f"{r2.body.op.test=}".split('=')[0]
'r2.body.op.test'

This also evaluates the expression, encodes the result as text then
discards it, which is undesirable. The point is that renaming r2, or the
fields of a BinOp (if it were project-local, not a stdlib object) would
cause the string to change in most existing IDEs.

Attempts to guess the name from the expression at runtime are futile and
a red herring. Trying to describe the desired semantics that way leads
to nonsensical ideas, I agree.

I'm not convinced this feature is widely useful. Here I'm just trying to
focus us on the *viable* semantics MRAB identified.

Jeff Allen
___
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/RQISFW5UV2EW6ZB3ZKUDNV2R45MWIH3O/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Chris Angelico

On Sat, 16 Sept 2023 at 10:20, Dom Grigonis  wrote:
>
> So following this thread, from your perspective and from what has been said 
> you can’t see or noticed any parts of it needing interpreter?

Correct. Trying to get a variable name from an object is nonsensical,
and trying to get a variable name from a text string is simply "return
the text string unchanged".

ChrisA
___
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/5DGG4NECPJ4UNCNTRNBE2OM7F2JGCGT3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Dom Grigonis

So following this thread, from your perspective and from what has been said you 
can’t see or noticed any parts of it needing interpreter?
DG

> On 16 Sep 2023, at 03:14, Chris Angelico  wrote:
> 
> On Sat, 16 Sept 2023 at 10:07, Dom Grigonis  wrote:
>> 
>> 
>>> def nameof(x): return x
>>> 
>>> print("This " + nameof("thing") + " is:", thing)
>> Can you explain what you meant by this code? How would this work in editor?
>> 
> 
> Frankly, I have no idea, because your **entire proposal** is
> predicated on some sort of automated tool for renaming variables.
> Without knowing the details of that tool, how can I tell you how this
> would work?
> 
> But if that tool can be taught that nameof indicates a variable name,
> then it can rename inside it just like it would rename anything else.
> 
> Your problem here is a limitation of the variable renaming tool. I'm
> suggesting a solution to that problem. This is not a language problem,
> it's an editor problem, so it needs an editor solution.
> 
> ChrisA
> ___
> 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/I6KUD7LCGYV4JES77A7PZDVBHWVIKXF3/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/IDOWZCWN6CPEVFOUZGDPRKD7QV36ZCHL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Chris Angelico

On Sat, 16 Sept 2023 at 10:07, Dom Grigonis  wrote:
>
>
> > def nameof(x): return x
> >
> > print("This " + nameof("thing") + " is:", thing)
> Can you explain what you meant by this code? How would this work in editor?
>

Frankly, I have no idea, because your **entire proposal** is
predicated on some sort of automated tool for renaming variables.
Without knowing the details of that tool, how can I tell you how this
would work?

But if that tool can be taught that nameof indicates a variable name,
then it can rename inside it just like it would rename anything else.

Your problem here is a limitation of the variable renaming tool. I'm
suggesting a solution to that problem. This is not a language problem,
it's an editor problem, so it needs an editor solution.

ChrisA
___
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/I6KUD7LCGYV4JES77A7PZDVBHWVIKXF3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Dom Grigonis



> def nameof(x): return x
> 
> print("This " + nameof("thing") + " is:", thing)
Can you explain what you meant by this code? How would this work in editor?

> 
> ChrisA
> ___
> 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/MRHSRDWF3IR6ZEC7HFE5VBPS2YW4CITX/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/7Y2AOC6ATEOCMIZNNJERSDUKF2L5DCVD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Dom Grigonis

Yes, I agree. This was exactly what I had in mind. Was good to find out that 
there is such implementation in other language.

DG.

> On 15 Sep 2023, at 17:00, Jeff Allen  wrote:
> 
> On 13/09/2023 17:21, MRAB wrote:
>> I think the point is to have an equivalent to C#'s 'nameof'. 
>> 
>> It would be evaluated at compile time to a string, but with the advantage 
>> that it's clear that it's a name and not some random string that just 
>> happens to look like a name. 
>> 
> I'd like to draw attention to this as the first contribution to the thread 
> that has given a precise meaning to the initial idea. It tells us both what 
> it means and why you might want it (at least if the OP agrees). It seems to 
> be being overlooked.
> 
> As others have amply demonstrated (short of proof, I know) what is being 
> asked is not possible with the information available at run-time. You can't 
> reliable get from the "reference", which is actually an expression, to the 
> text of the expression.
> 
> The parallel with f-string = is helpful, for which compile-time support is 
> essential, of course.
> 
> -- 
> 
> Jeff Allen
> ___
> 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/45P4HD5LBNDCPUGRRWWDV6XGR6H3GCDB/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/X6GLLYE3VAGCLCCWGQNGXJTISI2WMTXY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Chris Angelico

On Sat, 16 Sept 2023 at 08:50, Jeff Allen  wrote:
> The parallel with f-string = is helpful, for which compile-time support is 
> essential, of course.

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.

ChrisA
___
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/MRHSRDWF3IR6ZEC7HFE5VBPS2YW4CITX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-15 Thread Jeff Allen


On 13/09/2023 17:21, MRAB wrote:

I think the point is to have an equivalent to C#'s 'nameof'.

It would be evaluated at compile time to a string, but with the 
advantage that it's clear that it's a name and not some random string 
that just happens to look like a name.


I'd like to draw attention to this as the first contribution to the 
thread that has given a precise meaning to the initial idea. It tells us 
both what it means and why you might want it (at least if the OP 
agrees). It seems to be being overlooked.


As others have amply demonstrated (short of proof, I know) what is being 
asked is not possible with the information available at run-time. You 
can't reliable get from the "reference", which is actually an 
expression, to the text of the expression.


The parallel with f-string = is helpful, for which compile-time support 
is essential, of course.


--

Jeff Allen
___
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/45P4HD5LBNDCPUGRRWWDV6XGR6H3GCDB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-14 Thread Dom Grigonis

Good ideas, however not robust:
a = 1
b = 1
print(id(a))# 4536318072
print(id(b))# 4536318072

> On 14 Sep 2023, at 16:35, Jonathan Fine  wrote:
> 
> POSTSCRIPT
> 
> We can also use locals() to 'inverse search' to get the name, much as in the 
> original post.
> 
> >>> locals()['x']
> (0, 1, 2, 3)
> >>> id(x)
> 139910226553296
> >>> id(locals()['x'])
> 139910226553296
> -- 
> Jonathan
> ___
> 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/MPPLJ6MXZDNA7J75T7H76LNYZGHCEG37/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/7BXP63XG4PSQ2YFLCRXUEXJNNIQYEB4H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-14 Thread Stephen J. Turnbull

Jonathan Fine writes:

 > We can also use locals() to 'inverse search' to get the name, much
 > as in the original post.

As has already been explained, locals() (and any namespace for that
matter) is a many-one mapping, and therefore the inverse is not
well-defined.

At least for the 'print(f"count is {count}")' example, you really need
the compiler's help to get it right, unless you are willing to do it
the other way around:

def debug_name(name: str) -> None:
print(f"{name} is {eval(name)}")

but in general that's fraught with all the problems of using eval().

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/TIDEI74KQMEUCORSB7XMTBITDFYSK7D7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-14 Thread Jonathan Fine

POSTSCRIPT

We can also use locals() to 'inverse search' to get the name, much as in
the original post.

>>> locals()['x']
(0, 1, 2, 3)
>>> id(x)
139910226553296
>>> id(locals()['x'])
139910226553296
-- 
Jonathan
___
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/MPPLJ6MXZDNA7J75T7H76LNYZGHCEG37/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-14 Thread Jonathan Fine

Perhaps use the id of an object instead of its value. Here's how it might
work

>>> store = {}

>>> def wibble(fn):
...   val = fn()
...   name = fn.__name__
...   store[id(val)] = name
...   return val

>>> @wibble
... def ddd():
... return tuple(range(4))

>>> ddd
(0, 1, 2, 3)
>>> store[id(ddd)]
'ddd'
>>>

>>> x = ddd
>>> ddd = None
>>> store[id(x)]
'ddd'

I hope this helps.

-- 
Jonathan
___
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/V2RON2KVFVECTZMLXHJV3KJKNSLNQHA5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-13 Thread MRAB


On 2023-09-12 16:54, Rob Cliffe via Python-ideas wrote:



On 12/09/2023 11:54, Dom Grigonis wrote:

Yes, Thank you!

So 2 solutions now. They both solve what I have encountered. Beyond that, they 
differ by:

a) f-string print(f’{=a.method}’)   # ‘a.method’
No new builtin needed.
Simply reprints expression representation.


I don't understand your semantics either.  What would be the difference 
between your proposed

     print(f’{=a.method}’)
and simply writing
     print('a.method')
?

Would it be just that the syntax inside the curly braces is checked for 
legality,

so that
     print(f'{=!?}')
would not be allowed (presumably it would cause a SyntaxError)
?

Or do you want to check that the expression can be evaluated at run time?
You could achieve that by simply writing
     a.method

As for the example in your first post:
var = 710
variable_name = [k fork, v inlocals().items()ifv == 710][0]
print("Your variable name is "+ variable_name)

it does "work", but it doesn't make much sense with Python's semantics.  
You could have two identifiers bound to the same object; which one you 
got hold of would be essentially random.



I think the point is to have an equivalent to C#'s 'nameof'.

It would be evaluated at compile time to a string, but with the 
advantage that it's clear that it's a name and not some random string 
that just happens to look like a name.


For example, if you had, say:

print('The value of count is', count)

then an IDE wouldn't know that the "count" in the string literal is the 
name of the variable 'count', whereas in:


print('The value of', nameof(count), 'is', count)

it's clear that you're giving the name.

An IDE would be able to rename it correctly.

This:

print('The value of', nameof(count), 'is', count)

would be compiled as:

print('The value of', 'count', 'is', count)

Tell the IDE to rename 'count' to 'my_count' and you get:

print('The value of', nameof(my_count), 'is', my_count)

which would be compiled as:

print('The value of', 'my_count', 'is', my_count)

Telling an IDE to rename when you have:

print('The value of', 'count', 'is', count)

would give you:

print('The value of', 'count', 'is', my_count)

It would miss the string literal 'count', and you'd have to fix that by 
hand.

___
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/SX5PEP3UVDGTUD44RVBZHHKVJRWZOBKX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-12 Thread Rob Cliffe via Python-ideas




On 12/09/2023 11:54, Dom Grigonis wrote:

Yes, Thank you!

So 2 solutions now. They both solve what I have encountered. Beyond that, they 
differ by:

a) f-string print(f’{=a.method}’)   # ‘a.method’
No new builtin needed.
Simply reprints expression representation.


I don't understand your semantics either.  What would be the difference 
between your proposed

    print(f’{=a.method}’)
and simply writing
    print('a.method')
?

Would it be just that the syntax inside the curly braces is checked for 
legality,

so that
    print(f'{=!?}')
would not be allowed (presumably it would cause a SyntaxError)
?

Or do you want to check that the expression can be evaluated at run time?
You could achieve that by simply writing
    a.method

As for the example in your first post:
var = 710
variable_name = [k fork, v inlocals().items()ifv == 710][0]
print("Your variable name is "+ variable_name)

it does "work", but it doesn't make much sense with Python's semantics.  
You could have two identifiers bound to the same object; which one you 
got hold of would be essentially random.


Puzzled.
Rob Cliffe___
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/GTDF4Q2OYWWSTHWXTQI6TSEXHJIRWX4Z/
Code of Conduct: http://python.org/psf/codeofconduct/

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

I agree.

What I meant is that it is unreliable with `v is 710` and even more unreliable 
with `v == 710` as “==“ is less strict than “is”.

DG

> On 12 Sep 2023, at 21:03, Rob Cliffe  wrote:
> 
> 
>>> As for the example in your first post:
>>> var = 710
>>> variable_name = [k for k, v in locals().items() if v == 710][0] 
>>> print("Your variable name is " + variable_name)
>>> 
>>> it does "work", but it doesn't make much sense with Python's semantics.  
>>> You could have two identifiers bound to the same object; which one you got 
>>> hold of would be essentially random.
>> Yes, if `==` was replaced by `is`. Currently it is even more random as it 
>> would return the first one which evaluates __eq__() positively.
>> 
> I'm not sure what you're saying.  In:
> var1 = 710
> var2 = 710
> variable_names = [k for k, v in locals().items() if v is 710]
> Depending on the Python implementation, variable_names may be ['var1', 
> 'var2'] or it may be empty (depending on whether 710 is interned).  It could 
> also in theory contain one of 'var1', 'var2' but not the other, though I 
> would be surprised if that happened in practice.  The behaviour is not 
> guaranteed and should not be relied on.
> Rob Cliffe

___
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/JOCYEOKCQHEOLKF2LA2YMCFY7BL7XTKY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-12 Thread Rob Cliffe via Python-ideas




As for the example in your first post:
var = 710
variable_name = [k fork, v inlocals().items()ifv == 710][0]
print("Your variable name is "+ variable_name)

it does "work", but it doesn't make much sense with Python's 
semantics.  You could have two identifiers bound to the same object; 
which one you got hold of would be essentially random.
Yes, if `==` was replaced by `is`. Currently it is even more random as 
it would return the first one which evaluates __eq__() positively.



I'm not sure what you're saying.  In:
    var1 = 710
    var2 = 710
    variable_names = [k for k, v in locals().items() if v is 710]
Depending on the Python implementation, variable_names may be ['var1', 
'var2'] or it may be empty (depending on whether 710 is interned).  It 
could also in theory contain one of 'var1', 'var2' but not the other, 
though I would be surprised if that happened in practice.  The behaviour 
is not guaranteed and should not be relied on.

Rob Cliffe___
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/AI4OQP4SNIZORCI4JFJ5CV6QUVKIGYIB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Good points, thanks for reply.

> Or do you want to check that the expression can be evaluated at run time?
> You could achieve that by simply writing
> a.method
Yes, the point is that it would be checked for legality of expression itself. 
Whether to check if it actually evaluates without an error or not would both 
work. I see pros and cons in both cases. Maybe not evaluating is better as 
evaluation can always be checked separately if needed and eventually will be 
checked on actual usage anyway.

> As for the example in your first post:
> var = 710
> variable_name = [k for k, v in locals().items() if v == 710][0] 
> print("Your variable name is " + variable_name)
> 
> it does "work", but it doesn't make much sense with Python's semantics.  You 
> could have two identifiers bound to the same object; which one you got hold 
> of would be essentially random.
Yes, if `==` was replaced by `is`. Currently it is even more random as it would 
return the first one which evaluates __eq__() positively.

That's exactly why I started this. This was to illustrate that I could not find 
any robust way to do it.

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/O4UIFJQ7IYR2UZWYLNAQOOXQFJJNRXVT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Yes, Thank you!

So 2 solutions now. They both solve what I have encountered. Beyond that, they 
differ by:

a) f-string print(f’{=a.method}’)   # ‘a.method’
No new builtin needed.
Simply reprints expression representation.

b) print(nameof(a.method))   # ‘method’
New builtin.
Has its own logic.
Its extra functionality on top of what I have suggested can already 
achieved in python via a.method.__name__

I think f-string approach if optimal. It adds new feature, without 
functionality overlap and doesn’t crowd the namespace. Also, implementation is 
simpler as all what is required seems to be in the place already.

I have little preference regarding syntax, but
f’{=expression}’ does seem to make sense.

Regards,
DG

> On 12 Sep 2023, at 13:14, Valentin Berlier  wrote:
> 
> Do you mean something like C# nameof()? 
> https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof
> ___
> 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/USPQDMEA7ACWH2T56ZYTWBGG7SMT3RIF/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/P7KERJ2O5QWON5CZGM5LTMNVP4AZXHSK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

An addition to f-strings:
a = 1
b = 1
print(f'{a+b}') # '2'
print(f'{a+b=}') # 'a+b=2'
# I suggest adding this too
print(f'{=a+b}')# 'a+b'
It is different from putting it in quotes in a way how editors interpret it. 
E.g. changing the variable name in PyCharm would unambiguously change f-string 
as well, while it would not change the string literal.

Also, one could argue that it can just be extracted by 
`f’{a+b=}’.split(‘=‘)[0]`, but it is of course sub-optimal given the 
possibility that evaluation is expensive and not required.

DG.

> On 12 Sep 2023, at 13:06, Chris Angelico  wrote:
> 
> On Tue, 12 Sept 2023 at 20:05, Dom Grigonis  wrote:
>> 
>> Please read the next part of my e-mail too. It actually answer your question.
>> 
> 
> I did read it, and it didn't answer the question. Your desired
> semantics are not clear.
> 
> ChrisA
> ___
> 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/P5RHZPHTVREEYOG2VSBZYLA6UU33T2X3/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/6VVOWCY253PZPMTYNCEXGLH46YDAXN6S/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-12 Thread Valentin Berlier

Do you mean something like C# nameof()? 
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof
___
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/USPQDMEA7ACWH2T56ZYTWBGG7SMT3RIF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-12 Thread Chris Angelico

On Tue, 12 Sept 2023 at 20:05, Dom Grigonis  wrote:
>
> Please read the next part of my e-mail too. It actually answer your question.
>

I did read it, and it didn't answer the question. Your desired
semantics are not clear.

ChrisA
___
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/P5RHZPHTVREEYOG2VSBZYLA6UU33T2X3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Please read the next part of my e-mail too. It actually answer your question.

> On 12 Sep 2023, at 13:00, Chris Angelico  wrote:
> 
> On Tue, 12 Sept 2023 at 19:51, Dom Grigonis  wrote:
>> 
>> It wouldn’t. I know this is weird and not in line of how things work. This 
>> is more about simply getting reference variable name in locals() from the 
>> reference itself. But how would one access the variable name, when once 
>> called it returns the object it points to, not itself. So this would 
>> obviously require an exception in parser itself.
>> 
>> a = object()
>> b = a
>> print(a.__varname__)  # ‘a'
>> print(b.__varname__)  # 'b'
>> print((a + b).__varname__)  # Undefined??? ‘a + b’?
>> 
> 
> I don't understand your desired semantics. Do you just want to take
> whatever is given and put it in quotes?
> 
> ChrisA
> ___
> 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/ZWO3FPC2G2AWA5TNINBX4ZHDMKFBWQZN/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/U3R6MHLYKC6R7RX2LG7EACVLOPB6TH5N/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2023-09-12 Thread Chris Angelico

On Tue, 12 Sept 2023 at 19:51, Dom Grigonis  wrote:
>
> It wouldn’t. I know this is weird and not in line of how things work. This is 
> more about simply getting reference variable name in locals() from the 
> reference itself. But how would one access the variable name, when once 
> called it returns the object it points to, not itself. So this would 
> obviously require an exception in parser itself.
>
> a = object()
> b = a
> print(a.__varname__)  # ‘a'
> print(b.__varname__)  # 'b'
> print((a + b).__varname__)  # Undefined??? ‘a + b’?
>

I don't understand your desired semantics. Do you just want to take
whatever is given and put it in quotes?

ChrisA
___
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/ZWO3FPC2G2AWA5TNINBX4ZHDMKFBWQZN/
Code of Conduct: http://python.org/psf/codeofconduct/

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