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 -- http://mail.python.org/mailman/listinfo/python-list
