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 <dom.grigo...@gmail.com> 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 
>> <turnbull.stephen...@u.tsukuba.ac.jp 
>> <mailto: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/DSDPXKMPHAILIGWU5S45YXPPHH5KQRIH/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to