On Wed, Dec 13, 2017 at 11:50 AM, vitalije <[email protected]> wrote:
I didn't like the Type class. It can be replaced with named or even > ordinary tuple. > We'll see... > I couldn't find that you have instantiated it anywhere with last two > optional arguments. > Old cruft. > Also it defines method `__eq__`, but it is never used (or I didn't find > usage). > The code crashes without it. I don't like too many tracing code to be left inside code. > I understand, but for now it helps me understand what I *want* to do. I still don't know how you plan to resolve names to types. > These are the difficult resolve methods. > I don't see how it can be relevant for other cases? > That's what I am trying to understand. > Python 3.6 has added support for type annotations. > I am aware of annotations. I've written a tool that helps create annotations automatically. I've abandoned the idea of static type checking. However, the rope package does a pretty good job of that. It might be useful to add support for rope to Leo. If you have a concrete data structure that would allow type checking, and > that you can share (even if it is hand written for simple code example), I > would be glad to further develop my prototype for extracting all required > data from source code in a format that you need. > The present code makes some inferences. You can start by studying the resolve methods. 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.
