Consider Python Type Hints
Opened this issue · 4 comments
General thread : can / should python type hints be used intead of the existing micro-language used in the _def class attribute ? And maybe in the class representation, instead of the Python-Haskell hybrid language that is used today ?
Need some study here, but the general gist is that:
-
Type hints are obviously related to the problem at hand and they are "more standard" than my custom language (would require less explanation for users, implementation would be less arcane, etc.),
-
Maybe some (runtime) typechecking facilites (enforce, pytypes, pydantic, etc ?) could be leveraged with little extra developement ?
To begin with, I probably would have to create a few typical instance of type hints relevant for the description of pandoc elements and then see how these type hints can be introspected. For example: how can I get Meta and list[Block] from tuple[Meta, list[Block]] ? Block from list[Block] ? etc.
ATM I find the type hints hard to introspect. What I need i basically to be able to identify the components of things like tuple[Meta, list[Block]] and Union[Str, Space, ...]. Afaict ATM I would have to query some undocumented attributes (__name__, __args__ and or make some isinstance tests wrt to some typing classes).
It is also not clear how i would attached this info to pandoc classes ; somehow the type hint is for the class itself (typedefs), sometimes it applies only to the class arguments (constructors for sure ; and what would be the status for the union associated to an abstract data type ? It is the union itself ? Pretty much, yes). Unless I make sure that constructor ARE also type hints ?
Maybe I need to explore the librairies that do some runtime time-checking to see how they deal with this (that would be useful anyway).
A minimally invasive idea that could be worth considering: what would it take to have (optionally?) the constructors of all pandoc types check the type of their arguments ? No need to change the _def micro-language or anything built on top of it (at least at the moment), just a runtime mecanism to pinpoint a type issue as soon as it is encountered.
Consider giving the intell that some external runtime validation tool is expecting (typeguard, beartype, enforce, pytypes, pyteen, etc.)
The "optional" part is related to the possible performance hint for the creation of a large collection of new objects. OTOH, validation would be mostly shallow (right?), so maybe this would not be as bad as expected.
Nota: probably hard to use external validation tools and have typedefs by checked unless they are inlined into the type signature (?). Mmm unless I have already overriden isinstance for them and the type checker relies on this (?). Experiments needed ...