PEP 3107 Function Annotations for review and comment

[John Roth]

Tony Lownds wrote:
> > First, it only handles functions/methods. Python FIT needs
> > metadata on properties and assignable/readable attributes

>     ...
>
> > Third, it's half of a proposal. Type checking isn't the only use
> > for metadata about functions/methods, classes, properties
> > and other objects, and the notion that there are only going to
> > be a small number of non-intersecting libraries out there is
> > an abdication of responsibility to think this thing through.
> >
>
> That comes from this paragraph from the PEP:
>
>     There is no worry that these libraries will assign semantics at
>     random, or that a variety of libraries will appear, each with
>     varying semantics and interpretations of what, say, a tuple of
>     strings means. The difficulty inherent in writing annotation
>     interpreting libraries will keep their number low and their
>     authorship in the hands of people who, frankly, know what they're
>     doing.
>
> Perhaps you are right and intersecting libraries will become an issue.
> Designing a solution in advance of the problems being evident seems
> risky to me. What if the solution invented in a vacuum really is more
> of a hindrance?

Vacuum? What vacuum? Annotating programs for various tools
has a history that goes back almost to the beginning of programming
languages. It goes back even farther if you want to look at scholarly
use of natural language.

The only vacuum I see here is the focus on a solution
rather than a focus on a problem.

> There is a clear intersection between documentation packages and
> type-checking or type-coercing libraries. Documentation libraries can
> just use repr(annotation), possibly with a little bit of special
> casing to
> represent classes and types better.
>
> I'm not sure there will be an important use for overlap of different
> type-checking
> or type-coercing libraries within the same module. What else could
> intersect and
> why can't the intersecting pieces develop an solution when it arises?
>
> More feedback from the community on this point (whether the PEP needs to
> take responsibility for interoperability) would be nice.

At the moment the project I'm working on has annotations
from three packages: Python FIT (which is the actual package),
Ned Bachelder's code coverage tool, and one of the code
standards tools. None of these are either documentation
or type checking / coercion.

The point I'm making is that there are other uses for
annotations than type checking and documentation.
I specifically referenced Python FIT because it is neither
of these: it is an executable requirements test tool that
can be used as an acceptance test tool as well.

I also mentioned Naked Objects because it's got the
same issue: it needs type and other metadata information.
There isn't a current Python implementation that I'm
aware of, although I'm thinking of it as a next project.

> Thanks for the feedback from everyone so far,

I stripped the comment about syntax from this
response because I want to address it separately.

John Roth
> -Tony