'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!<fmt>}’ applies functions to v from builtin namespace: str/repr/ascii.
Em dom., 24 de set. de 2023 às 16:11, Dom Grigonis <dom.grigonis@gmail.com <mailto:dom.grigonis@gmail.com>> escreveu:
On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi <tiagoigirardi@gmail.com <mailto:tiagoigirardi@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.grigonis@gmail.com <mailto:dom.grigonis@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 <tiagoigirardi@gmail.com <mailto:tiagoigirardi@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.grigonis@gmail.com <mailto:dom.grigonis@gmail.com>> escreveu:
On 24 Sep 2023, at 16:42, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp <mailto:turnbull.stephen.fw@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))