> > P.S. A nit. I dislike "ok and" pattern. For example, I would rewrite > is_assign_to this way:
I don't mind your way of rewriting it. I used it just because I didn't know in advance all checks that need to be fulfilled, and `ok = ok and ...` gave me opportunity to put trace between any two and see what was the reason that some function returned False. Also, at some point I can use `ok = ok or ....`. I am glad that you liked this approach. If I knew more precisely what data you want to have after second pass, I would go for it. I didn't like the Type class. It can be replaced with named or even ordinary tuple. I couldn't find that you have instantiated it anywhere with last two optional arguments. Also it defines method `__eq__`, but it is never used (or I didn't find usage). It looks as if you thought it would be needed, but until it is really needed it just consumes brain power. I don't like too many tracing code to be left inside code. It consumes a lot brain cycles to read it and it hides real effective code. For example: all methods do_... take as an argument regex match and then again they throwaway input argument and compute same match once again. You said that patterns are defined where they are used, but it seems to me, that it was the case at some earlier stage, and now it is not the case. It is not as obvious mostly due to the presence of tracing code. If you turn on all of the traces I believe it would produce so much output that it would be challenging to read and understand traces. IMHO, traces should be always on while debugging one or two functions, but as soon as debugging is over, I would delete traces. For me it is much easier to delete and retype them even ten times if necessary than to read them all the time. Typing-in code is much cheaper than studying it. I still don't know how you plan to resolve names to types. I see relatively straightforward way to check and find the error in given example code, but I don't see how it can be relevant for other cases? Python 3.6 has added support for type annotations. Maybe that is the best way to define and check type conventions. When I ran my code on whole Leo code base I was puzzled by the fact that there is just a few places where pattern c.<ivar> = self is used. Notes-->@file ../doc/leoAttic.txt-->Unused code-->Static type checking... As you can see under 'Unused code'. How useful would be leoCheck in the end? Hopefully, I am missing something. 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. Vitalije -- 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 post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
