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

[Calvin Spealman]

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.

2) Decorator-based annotation consumers must be able to use the annotations
3) 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.