On Jun 7, 8:14 am, Mark Janssen <dreamingforw...@gmail.com> wrote:
> >> 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.
Fairly definitive terms have existed since 1985:
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>
> 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.
Cardelli and Wegner cited above call this ad-hoc polymorphism.
What you are calling polymorphism, they call universal polymorphism.
See sect 1.3 for a summary diagram
--
http://mail.python.org/mailman/listinfo/python-list
