Accessing undeclared field does not raise a type error about cinder HOT 2 OPEN

Yes, this is a case where we intentionally fall back to dynamic. The problem with strictly enforcing attributes is that we'd kind of like to be able to support cases where people are doing more dynamic things in building their class that our compiler doesn't necessarily understand (e.g. tacking on extra methods after the fact or via dynamic code in the class body, using class decorators that return the same type but maybe tack on extra stuff, maybe soon even some metaclasses); there's not much advantage to us in rejecting stuff like this (makes adoption harder) when we can just as easily fall back to dynamic and allow them to succeed or fail at runtime. Does it cause a problem for you?

I could potentially envision a stricter mode where we would enforce only using attributes that the compiler knows about; it's certainly not hard to implement. I think the ideal behavior here really depends somewhat on whether you are writing new code or trying to convert and gain whatever benefits you can in an existing dynamic codebase.

from cinder.

Understandable. This is not a problem for us. We just wanted to know if this fall-back-to-dynamic behavior is intended.

from cinder.