This post summarizes what I have learned about mypy. I had planned to include the mypy the discussions here, but I won't do so. The details would detract from the summaries I am about to give.
In the early 1980's I enjoyed playing the Colossal Cave Adventure <https://en.wikipedia.org/wiki/Colossal_Cave_Adventure> game. Well, the process of learning mypy is like playing that game, but it's a lot more fun :-) There is no right way to explore. Indeed, "mistakes" (and surprises) burn concepts into memory. Here is an (approximate) chronological list of my mistakes and Ahas: *Mistake 1*: Modify only TypeChecker.check_for_missing_annotations. Wrong! Adding default annotations to kwarg arguments should allow all checks to continue to work unchanged. Otoh, many unit tests may fail because they no longer give errors! *Mistake 2:* Use g.SherlockTracer to trace the *dynamic* calls. I spent a day improving Sherlock. Alas, the traces gave too many details and too few insights. *Aha 1*: Node.__str__ and Type.__repr__ are best for both users *and* devs. These methods pretty-print ast and type nodes by walking their respective trees with specialized classes. At first I thought the *serialize *methods would give me better data, but __str__ and __repr__ are *perfect*! *Aha 2*: All *.*accept *methods are tree visitors. In traces, a "visit" method (including another accept!) always follows accept. The next two Ahas relate to *transportation*, the ability to find necessary data. *Aha 3*: in TA.visit_callable_type, t.definition is either None or a FuncDef. The PR might not be possible without the link back to the FuncDef. The "t" var does not provide enough data. *Aha 4*: The SemanticAnalyzer (SA) class is more than just a tree walker! The SA class manages the entire semantic analysis phase. This class contains many useful ivars. For example, *sa.modules [sa.cur_mod_id] *contains the MypyFile (wraps an ast tree) for the current file. Finally, these two Ahas relate to the big picture: *Aha5*: load_graph (in build.py) parses all relevant files. It builds a graph for the builtins module that drags in many surprising files. At present, I don't understand why all these files are necessary. One would think that mypy needs special-case code for only Python's built-in functions <https://docs.python.org/3/library/functions.html>. This Aha explains why the SA calls sa.analyze_func_def so often. Happily, Aha 4 allows us to filter out extraneous calls. * Aha 6*: At some point (I don't remember when), I realized that *only* the SA class would need to change. There's no need to understand type inference! *Summary* This project is not quite retirement or a vacation. Nevertheless, it's great fun: 1. I give myself permission to make many false starts and mistakes. 2. There is no time pressure. I have stated that there is no timetable for the PR. 3. Exploring code with all of Leo's tools is inherently fun. My primary research tools are traces in three methods. I have spent days refining the output as I learn what data are most important. These semi-permanent traces show *patterns* that pdb can't. 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/bc902418-ca6a-41ab-94cb-389051816d82n%40googlegroups.com.
