[Python-3000] Traits/roles instead of ABCs

Talin talin at acm.org
Mon Apr 30 18:27:29 CEST 2007


Collin Winter wrote:
> The key part of traits/roles is that, because the system is separate
> from classes, you can do runtime role composition without a) mucking
> with __bases__, or b) making isinstance() and issubclass() squishy and
> ill-defined. By "runtime role composition", I mean it would be
> possible to do something like this at runtime:
> 
> py> int.implements(Ring)
> 
> or (depending on your spelling preferences)
> 
> py> Ring.implemented_by(int)
> 
> That is, it would be possible to distribute Jeffery's numeric kinds as
> a third-party library and still have them affect the built-in numeric
> types.

The question I have about all this runtime composition stuff is, what 
happens if different modules have different ideas about how things 
should be composed? How are conflicts resolved?

With ABCs, we have a limitation that is also a strength: The mapping 
between ABC and its bases is either built-in to the ABC or built-in to 
the class, meaning that these decisions have to all be made up front - 
which forces the ABC implementer to pre-decide the outcome of all such 
conflicts before they happen.

-- Talin


More information about the Python-3000 mailing list