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/
