[Cython] CEP 507/513

[Robert Bradshaw]

On Apr 18, 2008, at 12:53 AM, Dag Sverre Seljebotn wrote:
> Yes, I realize that CEP 513 must be cleaned up quite a bit at this  
> stage
> (these things happen -- concepts aren't clear in my mind until a week
> has passed and I can write it for the third time. I suppose  
> branding it
> a CEP right away was the error.). I've decided to spend my Cython time
> on exploring phase refactoring this week though, so I don't want to
> switch my trail of thoughts just yet (this lies much further ahead in
> time anyway). I'll work through the CEP in detail sometime later.

That's fine, it's good to put stuff in writing. Lots of CEPs have  
popped up recently (lots due to old ideas that hadn't been put down  
before) but I think perhaps things should be nailed down more/ 
discussed on the mailing list before a formal CEP is created  
(otherwise, at this rate, three-digit CEPs won't be enough :).

>
>> Reading CEP 513 again, I think the whole thing boils down to two  
>> things:
>>
>> 1) Automatic cimport on import, under certain conditions (e.g. if a
>> corresponding .pxd file is found in the internal cython path)
>> 2) Function overloading
>>
> Yeah. Likely it will end up as a small CEP advocating 1).
>
> Function overloading lives in CEP 502 (and is mentioned in my NumPy
> project proposal as well).
>
> Note that PEP 3124 is (unfortunately) deferred, as far as I can see?
> (however it wouldn't hurt to converge syntax with it anyway)

I agree. I think we want function overloading, as with static  
binding, non-python types, and external libraries we have a *lot*  
more to gain than plain vanilla Python. This makes me even more  
likely to accept function overloading without an explicit @overload  
decorator (for old-style typed functions where there can be no  
ambiguity).

> Not sure in what detail you meant, but I do consider it a bit unwieldy
> to have to use two different type declaration syntaxes (one for typing
> and one for overloading); I think one should treat the issue of
> overloading orthogonally to the issue of where the type is  
> declared. I.e.:

Yes. This has always been how I thought of it too.

> - One issue is declaring variables as Python types (my addition to CEP
> 507), if only as a simple typecheck facility. If not, overloading can
> only distinguish between builtins and builtins vs. object. (And I am
> perfectly ok with that because the stuff that I propose to use
> overloading for is mainly depending on C types or C types vs. object.)
>
> - Another issue is whether we add support for decorator-style type
> declarations. This would mainly have to do with the syntax and parser.
>
> In particular, I think there should be a 1:1 correspondance between  
> the
> functionality of
>
> def foo(int bar)
>
> and
>
> def foo(bar: int)
>
> (or, alternatively,
>
> @cython.typed
> def too(bar: int)
>
> in order to allow for other decorator use). The alternative (that  
> there
> are subtly different meanings between "T x" and "x: T") seems very
> confusing to use.
>
> With the @cython.typed decorator the contents of decorators can be
> treated in type context so it will be unambigious and the same as  
> today.

I don't like the idea of requiring @cython.typed everywhere, way too  
verbose. The "x: T" notation will have the disadvantage that if T is  
not interpretable as a type, it will just ignore it (maybe with a  
warning in strict mode or something).

> But there are usability problems;
>
> @cython.typed
> def foo(arr: ndarray(2))
>
> is going to look a lot more like calling the constructor ndarray, not
> using the parametrized type ndarray. (Which is why I ended up thinking
> we should make parametrized types look less like constructors,  
> somehow).

I agree with this.

>> Taking external types into consideration (see http://
>> www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/
>> extension_types.html#ExternalExtTypes ), I think the rest of the CEP
>> could be greatly simplified. It is possible I missed something not
>> covered by (1) and (2), but I believe this is the gist of the  
>> proposal.
>>
> I certainly has extension types in the back of my mind when I wrote  
> it,
> but that didn't cater for the CEP 507 addons and so.... I'll clean  
> it up
> some day.

OK. I added a comment to the top to that effect.

- Robert