On Friday, December 8, 2017 at 4:59:32 AM UTC-6, Edward K. Ream wrote: *tl;dr:* Read the summary
*> I am now in the process of putting this project on the back burner* Like the process of ending a project, deferring a project may be a protracted process, not a milestone or instant in time. Here are some additional thoughts, some to be transferred to #632 <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fleo-editor%2Fleo-editor%2Fissues%2F632&sa=D&sntz=1&usg=AFQjCNHWp07T0j2Gb0GMrZ1mP4Jkd5lgsQ> . 1. To *kill* this project I would have to prove that a convention checker could *never* find bugs that pylint or pyflakes miss. That assertion is simply false, as discussed below. So the project remains "alive". 2. Would I use such a checker if it existed? You bet I would! I would run it automatically whenever saving an external files, provided the pyflakes checks pass. 3. Is this project worthwhile? That's a much harder question! Here are some additional thoughts... *Using ast's* Previously I said, "Translating the prototype into ast-based code would instantly embroil me in all the old complexities." This statement is somewhat misleading. The regex patterns in the prototype detect class statements, def statements, and two kinds of assignments. Recognizing classes and defs in the ast tree happens automatically. Otoh, recognizing specific kinds of assignments using the ast is indeed clumsy. But for prototypes one could actually use the regex patterns *applied to the "dump" of the statement. *So this problem isn't a gotcha. *Computing known objects* The million-dollar question is: how many known types (of objects) can the checker compute *easily?* Well, some types *can* be computed easily. "self" is an instance of the class in which it appears. So for instance, if the bug fixed by #627 <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fleo-editor%2Fleo-editor%2Fissues%2F627&sa=D&sntz=1&usg=AFQjCNE7SrP703NXn1Vlrm53g3PSLKqPdw> where confined to a single class, a convention checker would have known what self.remove_tag refers to and thus could have detected that the p.v argument in the call does not match the p argument in the signature. Imo, this refutes the assertion that the checker could *never* find mistakes not found by pyflakes or pylint. Otoh, the process of resolving chains like x.y.z.func(...) remains murky. For example: # In the ctor self.tc = self.c.theTagController # In another method tc = c.theTagController tc.remove_tag(p,tag) The problem seems mysterious, after all these years. *Summary* This project will remain on the back burner unless I have some new insights into computing known objects. 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.
