Dom Grigonis writes:
> print(f'{=A.a}') # 'A.a'
> print(nameof(A.a)) # 'a'
I see that's the C# semantics, but it's not obvious to me why the
ambiguity introduced is worth emulating. The important aspect of the
proposed 'nameof' operator is that its argument can be validated by
the compiler and unambiguously recognized by refactoring tools. But
once it's a string, it loses those advantages. Why not be unambiguous?
I don't think that the tricks recommended (ie, typeof) to retrieve a
fully-qualified name in C# would be unambiguous in Python.
Also, Python's f-string '=' operator handles a broad variety of
expressions, not just attribute references. This has been useful to
me more often than bare names and attribute references.
> Both [member name and full reference] seem useful to me.
What am I missing? When would you want the member name only but
"nameof(<reference>).split('.')[-1]" would not do?
Also, are there use cases for the proposed nameof other than a more
flexible f-string '='? Ie, where only the str is wanted, not the
str-ified object? That clearly doesn't apply to the refactoring
application, though, unless you're communicating local names to
nonlocal computations or using eval, both of which seem like really
dubious practices to me.
> So the functionality is bound to an editor and anyone using another
> editor would just see a weird string?
No, they'd see an ordinary string. Editors would use heuristics to
recognize strings like f"the value of expression is {expression}". I
do stuff like this in Emacs all the time ad hoc, Chris is just
suggesting that some editors/IDEs would provide a more powerful and
accurate facility. I see while I was composing this Bruce Leban came
up with a very plausible convention, too.
> Use cases are mostly bug-free refactoring,
But the refactoring is very "meta" in the sense that you're creating a
string that refers to the name of an object. You either need an
external agent or computation which would be confused if the name were
incorrect, or to be using eval() for this to be an actual refactoring.
All of this seems very "code smelly" to me. If you're refactoring
this automatically, you're doing it wrong. ;-)
I don't see any use case that f-string '=' doesn't satisfy well enough
to make a new builtin pseudo-function[1] justifiable.
> E.g. would it be faster than `Class.__name__`?
You're working with strings expressing code. If it's about speed,
there's got to be a better way.
Footnotes:
[1] In C#, 'nameof' is first looked up as a function reference, and
if found that is called. Otherwise the compiler macro is used.
_______________________________________________
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/XC7QRRJN7DSF2AKDCMZWANQVOPJM65QI/
Code of Conduct: http://python.org/psf/codeofconduct/
