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/
