With the complexity of Leo, I think type annotations will be a Good Thing. I am a little concerned that when the typing issue settles down in future Python releases, the syntax may change enough that they would have to be redone.
On Saturday, June 26, 2021 at 3:53:58 PM UTC-4 Edward K. Ream wrote: > On Sat, Jun 26, 2021 at 7:41 AM David Szent-Györgyi <[email protected]> > wrote: > > "When and how to evaluate Python annotations" >> <https://lwn.net/Articles/858576/>. > > > Thanks for the link. Your post is timely. In the last few days, I have > gone from a mypy newbie to a mypy journeyman. Just today, in the > ekr-annotations branch, mypy passes the *fully* annotated version of > leoNodes.py. > > The following statement is almost completely wrong: > > "evaluating these annotations requires computation, so all programs pay > the price of the annotations, even if they are never needed." > > Annotations are pretty much the same as comments. They have no significant > cost. > > The following *is* a real problem: > > " forward references > <https://www.python.org/dev/peps/pep-0484/#forward-references> to types > that have not yet been defined requires using string literals, instead of > type name". > > The problem is dealing with the forward reference itself. Imo, the > ugliness of the string itself isn't significant. > > The typing module defines the TYPE_CHECKING constant > <https://docs.python.org/3/library/typing.html#typing.TYPE_CHECKING>, > which is *always* False at runtime. mypy, and other checkers, set this > constant to True while doing analysis. > > At present, the following appears at the start of leoGlobals.py: > > # Do the following imports *only* when running mypy. > if TYPE_CHECKING: # Always False at runtime. > import leo.core.leoCommands as leoCommands > import leo.core.leoNodes as leoNodes > assert leoCommands > assert leoNodes > > Yes, this is ugly, but it allows *string *annotations like this: > > def findTabWidthDirectives( > c:"leoCommands.Commands", p:"leoNodes.Position"): > > *Summary* > > Imo, annotations will become an important part of Leo. mypy isn't perfect, > but it is flexible and easy to use. I plan to fully annotate only Leo's > crown jewels (the modules corresponding to c, g, and p), namely the > leoCommands, leoGlobals, and leoNodes modules. mypy has already found about > a half dozen bugs that pylint and Leo's unit tests have missed. > > Leo will fail to start if leoGlobals.py imports any other Leo module. > leoGlobals.py can deal with forward references, as shown above. > > leoNodes.py also uses forward references to the Position and Vnode class, > but those references don't require the TYPE_CHECKING constant the > referenced classes appear in leoNodes.py. > > I care little or nothing what Python 3.10 may bring. Imo, mypy and > python's typing module seem sufficient just as they are. > > 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/8c448c59-e1b2-47a6-8235-ea524a90800en%40googlegroups.com.
