Skip to content

SymbolTableNode.kind conflates orthogonal characteristics #3440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
carljm opened this issue May 24, 2017 · 1 comment
Closed

SymbolTableNode.kind conflates orthogonal characteristics #3440

carljm opened this issue May 24, 2017 · 1 comment

Comments

@carljm
Copy link
Member

carljm commented May 24, 2017

I encountered this issue in working on #3435 -- it is the reason that PR stops short of implementing support for module aliasing assignment outside of module global scope. When I remove the not self.is_module_scope() guard in that PR, this line in the added test fails with an opaque error A: main:5: error: Member "m2" is not assignable.

I haven't yet traced through to fully understand what is happening, but I have a strong suspicion that the problem is due to SymbolTableNode.kind representing orthogonal characteristics of the symbol table node with mutually exclusive enum values.

SymbolTableNode.kind can take one of these values: https://github.com/python/mypy/blob/master/mypy/nodes.py#L34-L53

This enum isn't capable of representing the fact that a MODULE_REF might occur at global, member, or local level. In the test linked above, I think the symbol table entry really should be both MDEF and MODULE_REF, but that isn't representable; when my code tries to change the class attribute symbol table node from MDEF to MODULE_REF, things break. I think mypy implicitly assumes that MODULE_REF is global.

Hopefully I can find time to explore this further, verify the suspicion, and investigate possible solutions. Just wanted to record my findings so far publicly before leaving PyCon sprint. Comments/guidance welcome!

@carljm
Copy link
Member Author

carljm commented May 25, 2017

Closing this issue, it was bogus. The symptom is real (and fixed in #3450), but the speculation about the root cause was unfounded. These enum values are still pretty confusing, though.

@carljm carljm closed this as completed May 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant