On Mar 11, 2008, at 1:36 AM, Stefan Behnel wrote:
> 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,
Yeah, it could get ugly: cython.types.pointer(cython.types.pointer
(cython.types.int))." At this point string processing might not be
bad, i.e. cython.type("int**") or even "int**" if it's clear from
context that we're specifying a type. (I do want to avoid putting to
much semantic information into "black box" strings though).
> but if I understand
> this right, this proposal is only for type annotation of otherwise
> plain
> Python code, right?
Yep.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
