Just want to add to this as I encountered a case, where I think f-string would
be sensible to use. Third potential use case after logging & dictionary key
synchronisation with variables names.
Simply eval/exec string inputs. I sometimes use of these for ad-hoc callbacks.
Would be great if `v` was recognised as a code. Code is similar to this:
class A:
def __init__(self):
self.d = {'a': 1, 'b': 2}
def apply(self, smtp):
for k, v in self.d.items():
if callable(smtp):
self.d[k] = smtp(v)
elif isinstance(smtp, str):
self.d[k] = eval(f'{=v}{smtp}')
a = A()
print(a.d)# {'a': 1, 'b': 2}
a.apply(lambda x: x * 2)
print(a.d)# {'a': 2, 'b': 4}
a.apply('* 2')
print(a.d)# {'a': 4, 'b': 8}
Regards,
DG
> On 16 Sep 2023, at 20:43, Dom Grigonis wrote:
>
> 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
>> > > 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().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/DSDPXKMPHAILIGWU5S45YXPPHH5KQRIH/
Code of Conduct: http://python.org/psf/codeofconduct/
