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

Calvin Spealman ironfroggy at gmail.com
Wed Aug 16 03:21:22 CEST 2006


On 8/15/06, Collin Winter <collinw at gmail.com> wrote:
> On 8/15/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> > On 8/15/06, Collin Winter <collinw at gmail.com> wrote:
> >> 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'.
>
> How exactly do they "deduce" what Bar is, just from the "from bar
> import Bar" line? pychecker would have to import and compile the Bar
> module first. What if being able to import bar depends on some import
> hooks that some other module (imported before bar) installed? I guess
> you'd have to follow the entire import graph just to make sure. Oh,
> and you'd have to end up running the module being analysed in case
> *it* installs some import hooks -- or maybe it defines Bar itself.
>
> Your proposal isn't workable.
>
> Collin Winter

Any external tool, which would need to analyze the annotations
statically would either know what the module bar is and what the
object bar.Bar is, or it would ignore it. Thus it has no need to
import or statically parse the modules imported for annotation objects
at all. For example, you may 'from annodoc import doc' and then 'def
foo(a: doc("the only argument"))', so a documentation generator would
be aware of what the annodoc module was and doesn't need to introspect
it in order to understand the annotations.

You're outright refusal to accept the arguments against these points
of your proposal is dragging this discussion on to an unneeded length.
The majority consensus is pointing away from the dictionary
multi-annotations you try to propose or the leave-and-let-be stand
point you originally tried to keep, while type-based annotations seem
much more well agreed upon and has more support. This continually
stretching debate needs to reach a consensus and the best recepted
idea might not be yours.

We really need to see the PEP draft updated to reflect something of a
solution to these issues and there is much less debate than the volumn
of discussion would suggest, so the answers are clear enough to move
forward with.


More information about the Python-3000 mailing list