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