[Cython] CEP 507/513

[Robert Bradshaw]

On Apr 18, 2008, at 12:17 AM, Stefan Behnel wrote:
> Hi,
>
> Robert Bradshaw wrote:
>> 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
>>
>> The only reason Python didn't have (2) is because it had no way of
>> declaring types, and hence distinguishing between overloaded
>> functions (well, perhaps parameter count, but that's not very
>> compelling)). This will change in Python 3000 http://www.python.org/
>> dev/peps/pep-3124/ , and I think we should backport that to Cython
>> (maybe not the whole PEP, but overloadable functions using @overload
>> or type signatures. In math.pxd one would declare sqrt for several
>> native types, and the object one would be the fallback. Def vs. cdef
>> could be interchangeable at this level.
>
> The @overload decorator lives in a package called "overloading",  
> according to
> the examples.
>
> Would it make sense to distinguish between
>
>     from overloading import overload
>
> and
>
>     from overloading cimport overload
>
> ? Mind the "cimport" in the second example. Cython could handle  
> cimported
> decorators at compile time and move the evaluation of Python-imported
> decorators to runtime, thus not even caring about where the  
> decorator comes
> from or what it does.
>
> Should we use different semantics here or would this just  
> complicate things?

I think this would just complicate things...the semantics should be  
identical, but if we can do static linking we should. Sometimes  
runtime dispatching will be needed though.

cdef foo(int i):
     print "Got an int", i

cdef foo(double d):
     print "Got a double", d

It is clear overloading is intended, does one have to make it  
explicit? (I think probably so, just for consistency, even though I  
think it makes things unnecessarily more verbose.)

- Robert