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 
> <mailto:dom.grigo...@gmail.com>> escreveu:
> 
> 
>> On 24 Sep 2023, at 16:42, Stephen J. Turnbull 
>> <turnbull.stephen...@u.tsukuba.ac.jp 
>> <mailto: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 = 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/

Reply via email to