On Wed, Dec 13, 2017 at 12:32 PM, Edward K. Ream <edream...@gmail.com> wrote:
I was going out the door when I wrote my first brief replies. Several questions deserve longer answers. 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. > Furthermore, I have been thinking of this project as a way to peer into existing code. Let's use the term *reporter code* for this. I'll create the reporter code using the ast.walk + generator pattern or perhaps a rewritten ShowData class. Using separate reporter code should eliminate many traces. I still don't know how you plan to resolve names to types. >> > > These are the difficult resolve methods. > It's easy for me to forget that this is the *one and only* important question! In essence, the present code special-cases ivars injected from outside the class. They deserve special attention, but that special case is no substitute for a more general plan. As I think of this, it seems that the goals of the project are extremely limited, namely to check assignments (including correspondence of call args with signature) in *only* those case where naming conventions are used. As presently understood, inferences can only be as good or detailed as the data in the default classes dictionaries. Otoh, there are only a few official ivars (and chains of same) that Leo devs need to know about, so *maybe* these kinds of limited inferences *between* classes will suffice. One can imagine almost unlimited inferences *within* each class, but I really haven't put much thought into this. The disappointment I suffered a few days ago arises, I think, from the limited nature of the checks. > >> Python 3.6 has added support for type annotations. >> > I didn't make clear how much I dislike Python's type annotations. They may be useful in some cases, but imo they destroy the beauty of Python code. They have all the charm of C++ templates. They are likely to make refactoring code significantly harder. You could say that this project arises from the belief that Leo's naming conventions say almost as much annotations. Hope this clarifies my present thinking. I don't have a deep attachment to this project. It's already improved existing code, and the recent patterns you shared with us promise to collapse the complexity of one or more classes. Other than that, it may be that I'll abandon this project in just a few days. 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 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.
