On Jan 31, 2020, at 08:03, Soni L. <fakedme...@gmail.com> wrote: > > Consider: > > x=nameof(foo.bar) > > in today's python becomes: > > foo.bar > x="bar" > > and when running this you get an AttributeError or something. > > the benefit is that "bar" is only typed once, and the attribute access (and > thus error-raising code) is tied to the resulting string. either you change > both the attribute access *and* the resulting string, or you get an error. > (correct me if I'm wrong.)
That does work, but that means foo.bar has to exist and have a value before you look up the name. Consider these cases: class Spam: def __init__(self): self.eggs = 42 print(nameof Spam.eggs) # AttributeError class Foo: pass foo0 = Foo() setattr(foo0, nameof foo0.bar, 42) # AttributeError foo1 = Foo() print(nameof foo1.bar) # AttributeError foo1.bar = 42 foo2 = Foo() if spam: foo2.bar = 42 print(nameof foo2.bar) # AttributeError if not spam foo3 = Foo() Foo.bar = 23 print(nameof foo3.bar) # works fine baz = MyRPCProxy(baseuri, endpoint) print(nameof baz.bar) # makes a remote procedure call on the server and ignores the result or raises AttributeError depending on the server These all seem more confusing than helpful—and very different from C#. If you explain that nameof is a mix of compile time and run time, or just explain that it compile to the same thing as the code as you gave, people could figure it out, but it still seems both weird and undesirable. Python variables just don’t have a static type, and even if they did, the attributes are dynamic rather than determined by the type anyway. And that isn’t some edge case that occasionally comes up; that Spam example is the usual ordinary way for a class to give its instances attributes.) However, that does raise the possibility that maybe mypy (or your IDE or favorite other static type checker tool) should be doing the check, because Python variables often do have a static type and it often does declare the variables and “often” may not be good enough for language semantics but it’s exactly the point of optional gradual type checking. So: @dataclass class Spam: eggs: int = 42 spam.cheese # If your typing-aware IDE will flag this nameof spam.cheese # … it will do exactly the same here Now, when you’re using mypy/etc , nameof is just like C#, and gives you exactly the desired benefits, but all the Python compiler has to do is emit “cheese”. And when you aren’t using mypy? Then it just doesn’t get checked. Same as all other static typing errors. What happens if spam: Any, or if spam: Spam but Spam didn’t statically deflate its attributes? At first glance, given the way optional gradual typing generally works, this shouldn’t be an error. But if we think of nameof as a compile time operator that’s meant to act like C#, maybe it is a static typing error to use it on an attribute that can’t be statically checked? Or maybe a warning? I don’t know. Maybe that should even be left up to the type checkers as a QoI issue rather than defined by Python? _______________________________________________ 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/62GL6YJWPE6CKH7BLIYYQNNGAZLXBWEB/ Code of Conduct: http://python.org/psf/codeofconduct/