Hi,
Robert Bradshaw wrote:
> On Mar 10, 2008, at 4:48 PM, Dag Sverre Seljebotn wrote:
>> @cython(args=("x", cython.types.int), ret=cython.types.int, except=-1)
>> def foo(x):
>>
>> But it might be too verbose.
>
> IMHO, yes, this is getting way to verbose, but it could be accepted
> (though the P3K ways is preferred). Perhaps there could be a locals
> dict that is passed in as well, i.e.
>
> @cython(arg_types={"x": cython.types.int}, local_types={"square",
> cython.types.int}, return_type=cython.types.int, except=-1)
> def foo(x):
> square = x*x
> return square
And it would be trivial to implement with the decorator plugin infrastructure.
Remember my proposal to let compile time decorators operate on the parse tree?
In this case, it would traverse the tree of the function, and just annotate
all occurrences of parameters ("x"), the return value, exception raising, and
the named local variables ("square") with their provided types, *before*
running any further type inference or analysis steps over the tree.
Then, the type analysis step would already know the expected types and could
raise errors on assignments of unknown or unexpected types.
So we'd have a couple of interception points where decorators and plugins can
run: post-parse, pre-type-analysis, post-type-analysis, ... A plugin could
just set that up on registration and Cython would call it at the right time
and then continue working on the modified syntax tree.
One drawback of the decorator notation: I don't think you can express pointers
and external C types (structs etc.) in any sensible way, but if I understand
this right, this proposal is only for type annotation of otherwise plain
Python code, right?
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
