Collin Winter wrote:
> On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> 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
>
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
