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/

Reply via email to