[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 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