[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
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] Reconstructing datetime from microsecond timestamp
datetime.datetime has microsecond precision, and if you want to reconstruct a datetime from microseconds since the Unix epoch in a provided timezone, you can do: (datetime(1970, 1, 1, tzinfo=timezone.utc) + timedelta(microseconds=timestamp_us)).astimezone(tz) This is a general solution, but it constructs two extra datetimes and a timedelta on the way. datetime.fromtimestamp could bring that to just the one, but it takes float seconds, so there's no way to avoid losing precision (for far enough date in the future, but well short of datetime.max). One solution is to handle the micros separately: datetime.fromtimestamp(timestamp_us // 100, tz).replace(microsecond=timestamp_us % 100) This still requires constructing two datetimes, and it bakes in an assumption that the timezone offset doesn't affect and isn't affected by the millisecond component. (Which probably is the case! I think.) This might all be too much thought about edge cases that don't matter, but given the *_ns() functions in the time module (PEP 564), I'm curious why datetime doesn't have a constructor that takes an integer timestamp with the full precision that supports. Peace, -Sam ___ 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/46PNI5Z24OTYMIHG5JMTC4JLQHT35W2B/ 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
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
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
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
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/
