use str as variable name

[Fredrik Lundh]

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>