I now have strong doubts that #632 <https://github.com/leo-editor/leo-editor/issues/632> is worth more effort. Yes, it can catch an arcane bug or two, but it looks like that's about all it will ever be able to do.
As Vitalije points out, there really isn't much of a framework for doing inference. When I started this project I thought this limited framework might be a plus. Now, that notion seems pretty silly. The fundamental problem is that Leo's naming conventions will not to be able to find many bugs that pyflakes and pylint can't. Knowing about c.p, p.v, p.h, p.v.h, v.h etc. is good, sure, but devs aren't likely to make too many mistakes here. It might be possible to simplify the resolve* methods, perhaps greatly. But they can't create deductions from nothing. There is a dilemma here. On the one hand, resolve needs data. Otoh, we don't want the user to supply very much by hand. Supplying the data "automatically" implies real type inference, but I specifically excluded full type inference when I opened this project. The dilemma has an analog at the code level. do_assn_to_self is needed to catch the original but, but that's a tiny return on investment. do_assn_to_self mostly just adds useless data to dicts. We could only use that data by going down the type inference rabbit hole. *Summary* The limited nature of Leo's naming conventions appears to doom this project. Perhaps in retrospect this conclusions is obvious, but so what? I'll leave #632 open for a day or two while we discuss matters further. I have no regrets about working on this project. It's been engaging and real code improvements tangential to the project have resulted. 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.
