[Cython] CEP 507/513

[Dag Sverre Seljebotn]

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.

> 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)

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.:

- 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. 
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).

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


-- 
Dag Sverre