You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like we could remove the special handling of module references and other special node kinds in SymbolTableNode so that we could remove the kind attribute and replace it with a scope attribute, with only 3 possible values, corresponding to the current kinds LDEF, GDEF and MDEF. We'd create new SymbolNode subclasses for some of the node kinds. For module references we can perhaps just use a MypyFile target node as a marker. We could move some attributes that are specific to type aliases to live in the new SymbolNode subclass.
Type aliases are quite complicated (due to several corner cases). I tried to make some simplifications recently. It seems to me that we can introduce a dedicated SybmolNode (like Var or TypeInfo) and deprecate type_override and friends and just point .node to this new symbol node. This is major refactoring, but I think it may help.
The text was updated successfully, but these errors were encountered:
Actually it looks like having a dedicated ModuleRef symbol node will solve #3500 and other long standing problems with conditional imports and imports in try: ... except: .... We can have something like this:
It seems like we could remove the special handling of module references and other special node kinds in
SymbolTableNode
so that we could remove thekind
attribute and replace it with a scope attribute, with only 3 possible values, corresponding to the current kindsLDEF
,GDEF
andMDEF
. We'd create newSymbolNode
subclasses for some of the node kinds. For module references we can perhaps just use aMypyFile
target node as a marker. We could move some attributes that are specific to type aliases to live in the newSymbolNode
subclass.From #4080 (comment):
@ilevkivskyi :
The text was updated successfully, but these errors were encountered: