Agree, all good points. f'{=expr}'.split('.')[-1] Does take care of all cases and `nameof` has no additional use over it.
It seems that `nameof` is out of question. DG > On 16 Sep 2023, at 19:50, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > 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/K4QOZTA7B6VK324UHSSRXNF262VTOLLN/ Code of Conduct: http://python.org/psf/codeofconduct/