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

[Tim Hochberg]

Collin Winter 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.

Why does PyChecker need to "deduce" what Bar is at all? It seems that 
either bar.Bar is something that PyChecker knows about, because it 
indicates something that it knows how to check. Or, it's something it 
doesn't know about in which case it can safely ignore it. I fail to see 
any significant difference in


def foo(a: Bar(baz)): ...

versus

def foo(a: {'Bar' : baz}): ...

except that the latter is harder to read and more prone to name colisions.

> 
> Your proposal isn't workable.

I, at least, fail to see why at this point

-tim

>