Not sure what the intention is ... the quote below is interesting: if annotations make understanding Leo's codebase, I'd consider it a very worthy project.
>From the recent Python language summit: The state of mypy: https://lwn.net/SubscriberLink/690081/5c35679cafe42d1b/ "But he(Guido) and Dropbox have found it useful. Annotations are being added to a multi-million line application. Part of the reason is to help new employees come up to speed on that codebase. Rather than have to look through a million lines of code to figure out if a function returns a list or a dict, they can just consult the stub file—the .pyi file where type annotations are often placed—or get an error from mypy." Also: An introduction to pytype: https://lwn.net/SubscriberLink/690150/660acde532afb8a3/ On Thu, Jun 9, 2016 at 9:23 AM, Edward K. Ream <[email protected]> wrote: > Another thread points at the github repo for my nascent check-attrs project. > > I am going to put this on hold, at least for now. The problem is that > simply checking attribute chains isn't useful without a lot of other work, > and that other work gets mighty close to full type checking, or its > pattern-based equivalent. > > Instead, it would seem much more natural to use python's real type checker, > mypy. And studying mypy as I did with pyflakes may be in order, but perhaps > not right away (see below). > > Having said this, I am pretty sure that there is room for a design checker, > and that patterns, not type inference, are likely the way to specify the > design. As an easy example, the pattern: > > self.c = Commander > > specifies what should be a universal design pattern for Leo's source code. > This is, imo, very different from simply inferring that self.c is, in every > case, a Commander. Do you see? The pattern specifies intention. The > corresponding type inferences do not. > > Alas, this kind of simple insight quickly gets sucked down the rabbit hole > of endless inference loops, where each inference depends on everything else. > I had thought that patterns might cut the "Gordian Knot", but they seem, > instead, merely to add lots of special cases without handling the general > cases. Boo hoo. I have enough experience with inference engines to know > that special cases never simplify matters, despite my intuitions. > > For this reason, I think it is worthwhile to study, or at least to use, > real, general purpose inference, namely mypy. Happily, mypy can use stub > files to short-circuit inferences in a general manner. My make-stub-files > project meshes perfectly with this approach. > > I expect that experimenting with mypy will take only a day or three. > Studying the mypy code is possible. If I do that, I might budget 2 or 3 > weeks. However, I think there are enough important Leo bugs on the table > that it would be good to fix them asap. > > Your comments, please, Amigos. > > 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. -- 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.
