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/