[Python-Dev] type categories
David Abrahams" <firstname.lastname@example.org
Tue, 13 Aug 2002 23:59:29 -0400
From: "Guido van Rossum" <email@example.com>
> > That's funny, my users are very happy with how fast it works in
> > Boost.Python. I don't see any reason it should have to be much less
> > efficient in pure Python for most cases... the important "type
> > could be builtins. And as others have pointed out, it could even be
> > get certain optimzations.
> Time to write a PEP.
I don't know how these things usually work, but isn't it a bit early for
that? I would like to have some discussion about multiple dispatch (and
especially matching criteria) before investing in a formal proposal. That's
what my earlier posting which got banished to the types-sig was trying to
do. Getting a feel for what people are thinking about this, and getting
feedback from those with lots more experience than I in matters Pythonic is
important to me.
> Maybe there's an implementation trick you haven't told us about?
There's not all that much to what I'm doing. I have a really simple-minded
dispatching scheme which checks each overload in sequence, and takes the
first one which can get a match for all arguments. That causes some
problems for people who want to overload on Python float vs. int types, for
example, because each one matches the other. When I get some time I plan to
move to a more-sophisticated scheme which rates each match and picks the
best one. It doesn't seem like it should cause a significant slowdown, but
that's just intuition (AKA bullshit) talking. My users generally think
C++ = fast (but hard)
Python = slow (but easy)
[no rude remarks from the peanut gallery, please!]
So they don't tend to worry too much about the speed at the Python/C++
boundary, where this mechanism lies. It could be that they don't notice the
cost because they're putting all time-critical functionality completely
inside the C++ part.
David Abrahams * Boost Consulting
firstname.lastname@example.org * http://www.boost-consulting.com