The view model would be initiated from a generated set of code models. The separation between the two models could firstly be done with Protocol classes (so we keep a unique structure at first) defining all required attributes by astbuilder and templatewriter. Classes that would be used to annotate Documentable to restrict the attributes that can be accessed.
Then we could look at creating two sets of concrete classes.
The main challenge of that operation (and probably the reason it has not been done a long time ago) is that the code model is strongly couple with the docstring parsing. Namely:
the parsing of @ivar-like fields which creates model instance with parsed_docstring attribute already populated.
the handling of property definitions which creates model instance with parsed_docstring attribute already populated.
The main goal being not perform docstring parsing until we have the final state for all objects. This issue might be solvable with an ast transformer. But I need to dig into that problematic a little bit - for instance we need to ensure that the line numbers are not altered by the transformation.
Once we really have this separation, we'll be abler to look at making our parser interchangeable.
The view model would be initiated from a generated set of code models. The separation between the two models could firstly be done with Protocol classes (so we keep a unique structure at first) defining all required attributes by
astbuilderandtemplatewriter. Classes that would be used to annotateDocumentableto restrict the attributes that can be accessed.Then we could look at creating two sets of concrete classes.
The main challenge of that operation (and probably the reason it has not been done a long time ago) is that the code model is strongly couple with the docstring parsing. Namely:
@ivar-like fields which creates model instance withparsed_docstringattribute already populated.parsed_docstringattribute already populated.The main goal being not perform docstring parsing until we have the final state for all objects. This issue might be solvable with an ast transformer. But I need to dig into that problematic a little bit - for instance we need to ensure that the line numbers are not altered by the transformation.
Once we really have this separation, we'll be abler to look at making our parser interchangeable.