On Tuesday, June 29, 2021 at 5:01:18 AM UTC-5 Edward K. Ream wrote: #1944 <https://github.com/leo-editor/leo-editor/issues/1944> suggests > adding annotations for Leo's most important files. > > At present, within the* ekr-annotate* branch, mypy passes all of Leo's > core files without complaint, with the settings in leo-editor/.mypy.ini. > > Alas, many of the type annotations are redundant. The effect is a > substantial *increase *in code clutter and a *decrease *in readability. >
Let me summarize my thoughts about mypy, type annotations, and related topics. *Learning mypy* As I said in another thread, it took only a few days to become comfortable with mypy. mypy is a superb tool. *Annotations have revealed bugs* For example, ec.centerLine, in leo/commands/editCommands.py, mypy showed that the "cast" to int is necessary in: n = (fillColumn - len(line)) / 2 ws = ' ' * int(n) # mypy. *mypy isn't worth the cost of annotations* Imo, despite finding a few new bugs, the costs (in readability) of annotations outweigh the benefits of using mypy. Instead, pyflakes, pylint, and especially coverage tests provide more protection without odious annotations. *Leo is a static program written in a dynamic language* The type annotations in the ekr-annotate branch confirm something that I have long suspected, namely that I *do* know the types of almost all the data that Leo uses :-) *Leo could be rewritten in C or Rust without compromising what Leo can do*. Yes, python is a privileged language within Leo, but c.general_script_helper shows that python isn't *that* privileged :-) Nevertheless, there are at least two huge advantages to using python: 1. python handles storage allocation automatically. There is no need to handle storage allocation manually (as in C) or keep track of the lifetimes of objects, as in Rust. 2. The python interpreter provides a safe and fast environment in which to run buggy programs. Finally, slots show that Leo's plugins can customize Leo without altering Leo's Position and VNode classes. *The way forward* It would be feasible to merge the bug fixes from the ekr-annotate branch into devel by hand. I could then just delete the ekr-annotate branch. However, a *wax-off script* would help remove the annotations, thereby mostly automating the merge. A few regex search/replace operations would constitute a prototype wax-off, but a proper Leo script seems like a better strategy. The wax-off script would benefit from Leonine settings, in one or more @data nodes. These settings would tell wax-off which annotations merely state Leo's standard naming conventions. The wax-off script might remove such *standard annotations*, leaving behind more interesting annotations. We would likely want several @data nodes because which annotations are considered standard might depend on the particular file. The standard annotations for leoAst.py will be very different from the standard annotations for the rest of Leo. Similarly, a *wax-on script* would insert standard annotations, using @data nodes to discover which annotations are standard. Once the wax-on and wax-off scripts work, I'll convert them to Leo commands, say *insert-annotations* and *delete-annotations*. These commands will add or remove annotations on the selected file or files, guided by @data nodes. These commands might be of general interest. *Summary* Using mypy has taught me the value and limits of type checking. My long-time interest in static type checking is nearing its end. For me, type annotations are not worth their visual cost. The *insert-annotations* and *delete-annotations *will add or remove annotations on the selected file or files, guided by @data nodes. I'll use the delete-annotations command to remove some (or all!) type annotations from a new ekr-annotate branch, thereby allowing me to merge a few bug fixes into devel semi-automatically. The remaining work on annotations should take about a week. The work could be pushed back to Leo 6.5 if necessary, but there is no way that the ekr-annotate branch will become a permanent branch. Your comments, please. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/ff9657b8-465b-4361-b936-b7c93834daaen%40googlegroups.com.
