[Python-3000] Fwd: Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations) (original) (raw)

Calvin Spealman ironfroggy at gmail.com
Wed Aug 16 00:20:14 CEST 2006

On 8/15/06, Collin Winter <collinw at gmail.com> wrote:

On 8/15/06, Paul Prescod <paul at prescod.net> wrote: > On 8/15/06, Collin Winter <collinw at gmail.com> wrote: > > How is > > this significantly better than my dict-based approach, which uses > > standardised dict keys to indicate the kind of metadata? > > The dict-based approach introduces an extra namespace to manage. What if two > different groups start fighting over the keyword "type" or "doc" or "lock"?

How do you foresee this arising? Do you think users will start wanting to apply several different typechecking systems to the same function? The idea behind these standard keys is to a) keep them limited in number, and b) keep them limited in scope. At the moment, I can only foresee two of these: "type" and "doc". My justification for "type" is that users won't be using multiple type systems on the same parameter (and if they are, that their own problem); for "doc" is that a docstring is just a Python string, and there's really only own way to look at that within the scope of documentation strings. Beyond these applications, the annotation consumers are on their own. Consumers that operate in the same domain may well coordinate their keys, and popular keys might make it into the list of standard keys (like the process for getting a module into the stdlib). I hope to have a second draft of the pre-PEP within a few days that includes this idea. Collin Winter

The dictionary approach, although it is what I was originally planning to support, is just too ugly and too limited. String keys can be ambiguous, but objects can not. The arguments against the better approaches, which you keep trying to repeat, just don't hold up. The non-dictionary, multiple annotation proposals can stand up to your requirements perfectly, and fulfill the requirements even better than the dictionary approach.

  1. Static analysis tools (pychecker, optimising compilers, etc) must be able to use the annotations

As in any example given so far, the annotations would be instansiated within the function definition itself, which means the form 'def foo(a: Bar(baz))' is to be expected. This form could even be documented as the prefered way, as opposed to instansiating the annotation object before hand and simply using its name in the function definition. This leads to simple parsing by external tools, which would be able to deduce what bar is (because before that line there was an 'from bar import Bar'.

Dictionary string keys are just too limited and offer too much chance for conflicts. Better to avoid them now than after there are established and conflicting libraries expecting different things.

  1. Decorator-based annotation consumers must be able to use the annotations
  2. Non-decorator-based annotation consumers (pydoc, etc) must be able to use the annotations

A simple filter on the type of the annotations (maybe a helper function in some basic annotation utility library would be helpful) will help any consumer get the types of annotations it needs.

In the end, the biggest argument against the dictionary approach is that it is simply too ugly, and would be almost impossible to get around for even a single annotation on a parameter.

More information about the Python-3000 mailing list