On 26 maj 2013, at 01:07, PJ Eby <p...@telecommunity.com> wrote: > The PEP uses the term "implementation", and I think that > actually makes a lot of sense: a generic function is composed of > functions that implement the same operation for different types.
All suggested changes applied. There are still a couple of mentions of "overloads" and "overloading" in the PEP but they are unambiguous now and always refer to the general mechanism. > Last, but not least, there should be a stacking example somewhere in > the doc, as in the PEP I swapped the old examples from the docs and reused the PEP API docs in their entirety. This way it's easier to keep things consistent. > (It may also be useful to note somewhere that, due to caching, > changing the base classes of an existing class may not change what > implementation is selected the next time the generic function is > invoked with an argument of that type or a subclass thereof.) I don't think it's necessary. Abstract base classes present the same behaviour and this isn't documented anywhere: >>> from abc import ABC >>> class FirstABC(ABC): pass >>> class SecondABC(ABC): pass >>> class ImplementsFirst(FirstABC): pass >>> assert FirstABC in ImplementsFirst.__mro__ >>> assert issubclass(ImplementsFirst, FirstABC) If we change bases of the class, it no longer reports the first in the MRO: >>> ImplementsFirst.__bases__ = (SecondABC,) >>> assert FirstABC not in ImplementsFirst.__mro__ >>> assert SecondABC in ImplementsFirst.__mro__ >>> assert issubclass(ImplementsFirst, SecondABC) But it still reports being a subclass: >>> assert issubclass(ImplementsFirst, FirstABC), "sic!" -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
