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).
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").
- 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).
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
