Yes, it seems it does have scope beyond editor in both cases. class A: a = 1
print(f'{=A.a}') # 'A.a' print(nameof(A.a)) # 'a' In f-string case, if to be consistent with current f-string functionality, expression would be checked for a validity and that reference is in scope and available. Essentially, everything that `f{A.a=}` does now, except actual evaluation. In `nameof` case, it only prints the name of the last attribute and drops the tail. It is also naturally checked for validity. Both seem useful to me. > It works already with existing tools that will treat "nameof(a+b)" as a > function call, which it is syntactically but not semantically, so renaming b > to c will now produce the string "a+c". I think my IDE does offer to do this > with variable names in strings and comments, but it produces so many false > hits I don't enjoy using the feature. So the functionality is bound to an editor and anyone using another editor would just see a weird string? After several similar editor features things could get very confusing. > I'm not convinced this feature is widely useful. > So what is the general procedure for determining it? On a side note, I have stumbled on this stack thread: https://stackoverflow.com/questions/31695900/what-is-the-purpose-of-nameof <https://stackoverflow.com/questions/31695900/what-is-the-purpose-of-nameof> Use cases are mostly bug-free refactoring, but some are using it for resource check at compie time. Also, certain cases C# offer speed benefits. E.g. would it be faster than `Class.__name__`? DG > On 16 Sep 2023, at 12:44, Jeff Allen <ja...@farowl.co.uk> wrote: > > On 16/09/2023 01:14, Chris Angelico wrote: >> But if that tool can be taught that nameof indicates a variable name, >> then it can rename inside it just like it would rename anything else. >> Your problem here is a limitation of the variable renaming tool. I'm >> suggesting a solution to that problem. This is not a language problem, >> it's an editor problem, so it needs an editor solution. > It needs language (parser) support because it does what you identified early > on: "take whatever is given and put it in quotes", where "whatever is given" > is the text of the expression only available at run-time. (Actually, I can > think of something complicated one might possibly do with the text produced > in exceptions, but please don't.) > Taking an example from my REPL just now (it happens that r2 is the AST of an > Expression), you could simulate nameof with f-strings: > > >>> f"{r2.body.op.test=}" > 'r2.body.op.test=42' > >>> f"{r2.body.op.test=}".split('=')[0] > 'r2.body.op.test' > > This also evaluates the expression, encodes the result as text then discards > it, which is undesirable. The point is that renaming r2, or the fields of a > BinOp (if it were project-local, not a stdlib object) would cause the string > to change in most existing IDEs. > Attempts to guess the name from the expression at runtime are futile and a > red herring. Trying to describe the desired semantics that way leads to > nonsensical ideas, I agree. > > -- > > Jeff Allen > _______________________________________________ > 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/RQISFW5UV2EW6ZB3ZKUDNV2R45MWIH3O/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ 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/SWM5ZL6X3TQV24OAPQOH3GI4UNPV2AJL/ Code of Conduct: http://python.org/psf/codeofconduct/