Marco Bizzarri wrote:
Just a question: "generic functions" are not meant in the sense of
"generic functions" of CLOS, am I right?
>>
it's meant in exactly that sense: len(L) means "of all len() implementations
available to the runtime, execute the most specific code we have for the
object L".
It is a generic functions like a CLOS one, as long as we remain to one
parameter.
I mean, there will be just one implemenatation of
foo(bar, man)
which the python interpretr can find; am I right?
Let's see if I can sort this out without causing even more confusion.
The Python *language* doesn't support generic functions in the CLOS
sense, but a given Python *implementation* may use a dispatching
machinery to select the best possible implementation for any call to a
built-in function.
Or in other words, the len() function shouldn't just be seen as a
function that *always* does
def len(L):
return L.__len__()
because if you look under the covers, it might be more like (using a
hypothetical Python dialect):
def generic len(L: list):
return list::get_size(L) # fast internal dispatch
def generic len(L: tuple):
return tuple::get_size(L) # fast internal dispatch
def generic len(L: object):
return L.__len__() # fallback behaviour, using method dispatch
where "len" represents a plurality of possible "len" implementations.
How the dispatching is actually done is up to the specific Python
implementation; CPython, for example, offers a "slot" mechanism for
types implemented in C that's quite a bit faster than the method call
machinery. And the slot mechanism isn't always single dispatch. For
example, internal getattr(obj, name) calls use one of several slots,
depending on what "name" is.
Other Python implementations may use different approaches, but the point
remains: a builtin function "operation(a, b, c)" isn't always mapped to
"a.__operation__(b, c)" by the runtime; code that uses the latter form
may be less efficient. And it's definitely less Pythonic.
</F>
--
http://mail.python.org/mailman/listinfo/python-list
