>> I am aware of what it means, but Python doesn't really have it (although
>> it may evolve to it with annotations).
>
> No polymorphism huh?
>
>
> py> len([1, 2, 3]) # len works on lists
> 3
> py> len((1, 2)) # and on tuples
> 2
> py> len({}) # and on dicts
> 0
> py> len('I pity the fool') # and on strings
> 15
> py> len(b'\x23') # and on bytes
> 1
> py> len(set(range(2))) # and on sets
> 2
> py> len(frozenset(range(4))) # and on frozensets
> 4
> py> len(range(1000)) # and on range objects
> 1000
Okay, wow, it looks like we need to define some new computer science
terms here.
You are making an "outside view of a function" (until a better term is
found). So that give you one possible view of polymorphism. However,
*within* a class that I would write, you would not see polymorphism
like you have in C++, where it is within the *function closure*
itself. Instead you would see many if/then combinations to define
the behavior given several input types. I would call this simulated
polymorphism.
But don't quote me on this because I have to review my 20 years of CS
and see if it matches what the field says -- if the field has settled
on a definition. If not, I go with the C++ definition, and there it
is very different than python.
But then, you weren't going to quote me anyway, right?
--
MarkJ
Tacoma, Washington
--
http://mail.python.org/mailman/listinfo/python-list
