In the "Leo in 2017" post I wrote: "I recently realized that pep484 <https://www.python.org/dev/peps/pep-0484> contains a suggested syntax for type-comments <https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code>. This would allow Leo to use mypy. To do this, I will adapt the make-stub-files script so it inserts those comments."
Happily, I think we can say, this "resolution" did not survive its first contact with a program that actually uses type hints, namely stubgen.py <https://github.com/python/mypy/blob/master/mypy/stubgen.py>. After importing and studying this file, I was left with a strong feeling of distaste for type annotations. They clutter code much like braces do. After a little thought, I realized that Leo's naming conventions for vars and ivars render such annotations superfluous. We don't need to be told what c, g, p, s, ch, i, j, k or aList mean! So type hints, whether "built-in", as in stubgen.py, or in comments, as in pep 484, will likely never be part of Leo. Finally, I have never understood the type calculi needed by type checkers. Putting aside the burden of trying to understand it all is a relief. I am happy to leave it all to others. I don't want, ever, to see unions and intersections of possible types in Leo's source code. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
