On Tuesday, December 12, 2017 at 11:58:07 AM UTC-6, Edward K. Ream wrote: > My previous bad/fatal decisions all related to worrying about details instead of focusing on inference.
Lately I've been using the mental trick of trying to make the code *slower* than before, by making more inferences or by making the code more general. This is a partial antidote to my typical obsession with speed. In a production version, it might be good to make both the ast node and its stringized version available at all times. The ast is required to handle nested classes, but the string representation of statements should also be useful. How else to honor user settings? Well, maybe there are other ways. This is an open question. A few words about generators: 1. Generators can make debugging difficult, because tracing their state *always* consumes them. I've asked Guido and other Python guru's about this. list(aGenerator) doesn't always work for debugging. This was a serious problem when trying to find the deep pylint bug. I couldn't see the intermediate generator states! 2. Having said that, using a generator/functional pattern for the resolve* methods could be a very good idea. I see no obstacle to doing so. This might be the most important takeaway from our discussion. 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.
