On May 22, 2008, at 11:35 AM, Dag Sverre Seljebotn wrote:
> Stefan wrote:
>> Hi,
>>
>> Dag Sverre Seljebotn wrote:
>>> http://wiki.cython.org/enhancements/compiledducktyping
>>
>> Isn't the overloading stuff what PEP 3124 is heading for?
>>
>> http://www.python.org/dev/peps/pep-3124/
>>
>> I think parameter annotations would make sense here.
>
> Compile-time duck typing is not really just overloading, it is
> overloaded
> template methods, i.e. like this in C++:
>
> template <typename A, typename B>
> A max(A a, B b) {...}
>
> (Unlike overloading, compile-time ducktyping has no Java equivalent).
The last thing I want to do is head down a path of trying to
reimplement C++. It has a lot of very powerful features, but they
come at a cost. Perhaps if it can be pulled off smoothly enough
though...
> It is *implemented* by having multiple overloaded functions
> internally,
> but making overloading possible is an (intended) side-effect. PEP
> 3124 can
> very easily be implemented in addition on top of my proposal, but I
> believe it too is orthogonal to what I'm proposing.
>
> The idea was to kill many birds with one rock:
>
> - Real Cython macros
>
> - Possible to drop typing in a lot of places (brings us closer to type
> inference), leading to very convenient and easy optimizations. This
> will
> just work:
>
> def max(a, b): return a if a >= b else b
>
> and work "like in Python" without any performance penalties or
> change in
> behaviour from coercing back and forth to object (if you just
> skimmed the
> proposal you might have missed the controversial bit where I suggested
> that "def" should just change behaviour (in a backwards-compatible way
> though), rather than introducing a "duckdef").
It should come as no surprise that I don't like the keyword
"duckdef." On the other hand, automatically treating all def
functions in this way is scary (imagine several copies of a 1000 line
def function, and picking an arbitrary cutoff is, well, arbitrary).
It also seems a bit too magic for def functions--if anything this
should be applied to cdef functions instead. The "two kinds of C
types" has me worried too, and another concern is how to properly
deduce the return type. (Maybe given the inputs, it would re-analyze
the function and pick the type of the return statement?)
Another option (just throwing it out, not convinced it's better) is
being explicit like
cdef max(generic a, generic b):
return a if a >= b else b
where "generic" is a special type. Or a keyword could be given as in
cdef generic max(a, b):
return a if a >= b else b
or it could be restricted to inline functions (where it would
obviously have the most use).
> - Overloading (as in, different behaviour for different object
> types) is
> sort-of made possible through the use of "isinstance" like in
> (current!)
> Python, so there is less to learn. If we want to, PEP 3124 can be
> implemented in addition (with the same spec, i.e. map it to a list of
> isinstance tests).
The overloading mechanisms of PEP 3124 seem much cleaner than a list
of isinstances, and I would suggests perhaps that cdef functions
could be overloadable by default. But, as you said, this is somewhat
orthogonal.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
