> 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/