> 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 <dom.grigo...@gmail.com 
> <mailto:dom.grigo...@gmail.com>> 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 
>> <mailto: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/XSX3FIG6ECUXJPD5HXJ2V43GCHYI276X/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to