The check-attrs project: on hold

[Edward K. Ream]

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

[Kent Tenney]

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/

> --
> 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+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Thu, Jun 9, 2016 at 12:32 PM, Kent Tenney <kte...@gmail.com> wrote:

From the recent Python language summit:

The state of mypy: https://lwn.net/SubscriberLink/690081/5c35679cafe42d1b/

​...​

An introduction to pytype:
https://lwn.net/SubscriberLink/690150/660acde532afb8a3/

​Thanks for these links.  The more I think about type checking, the more confused I become, so having real code (and docs!) to study seems like the only way forward.

The dream seems simple: to have a really quick type checker that catches most errors. That is: pyflakes is to pylint as X is to mypy/pylint.

EKR