On Jan 31, 2020, at 08:03, Soni L. <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/62GL6YJWPE6CKH7BLIYYQNNGAZLXBWEB/
Code of Conduct: http://python.org/psf/codeofconduct/
