straitSimple Traits for Python</pre><?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4.1: http://docutils.sourceforge.net/" />
<title>A simple implementation of traits for Python</title>
<meta name="author" content="Michele Simionato" />
<meta name="date" content="2009-01-10" />
<style type="text/css">
.highlight { background: #f8f8f8; }
.highlight .c { color: #408080; font-style: italic } /* Comment */
.highlight .err { border: 1px solid #FF0000 } /* Error */
.highlight .k { color: #008000; font-weight: bold } /* Keyword */
.highlight .o { color: #666666 } /* Operator */
.highlight .cm { color: #408080; font-style: italic } /* Comment.Multiline */
.highlight .cp { color: #BC7A00 } /* Comment.Preproc */
.highlight .c1 { color: #408080; font-style: italic } /* Comment.Single */
.highlight .cs { color: #408080; font-style: italic } /* Comment.Special */
.highlight .gd { color: #A00000 } /* Generic.Deleted */
.highlight .ge { font-style: italic } /* Generic.Emph */
.highlight .gr { color: #FF0000 } /* Generic.Error */
.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */
.highlight .gi { color: #00A000 } /* Generic.Inserted */
.highlight .go { color: #808080 } /* Generic.Output */
.highlight .gp { color: #000080; font-weight: bold } /* Generic.Prompt */
.highlight .gs { font-weight: bold } /* Generic.Strong */
.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */
.highlight .gt { color: #0040D0 } /* Generic.Traceback */
.highlight .kc { color: #008000; font-weight: bold } /* Keyword.Constant */
.highlight .kd { color: #008000; font-weight: bold } /* Keyword.Declaration */
.highlight .kp { color: #008000 } /* Keyword.Pseudo */
.highlight .kr { color: #008000; font-weight: bold } /* Keyword.Reserved */
.highlight .kt { color: #008000; font-weight: bold } /* Keyword.Type */
.highlight .m { color: #666666 } /* Literal.Number */
.highlight .s { color: #BA2121 } /* Literal.String */
.highlight .na { color: #7D9029 } /* Name.Attribute */
.highlight .nb { color: #008000 } /* Name.Builtin */
.highlight .nc { color: #0000FF; font-weight: bold } /* Name.Class */
.highlight .no { color: #880000 } /* Name.Constant */
.highlight .nd { color: #AA22FF } /* Name.Decorator */
.highlight .ni { color: #999999; font-weight: bold } /* Name.Entity */
.highlight .ne { color: #D2413A; font-weight: bold } /* Name.Exception */
.highlight .nf { color: #0000FF } /* Name.Function */
.highlight .nl { color: #A0A000 } /* Name.Label */
.highlight .nn { color: #0000FF; font-weight: bold } /* Name.Namespace */
.highlight .nt { color: #008000; font-weight: bold } /* Name.Tag */
.highlight .nv { color: #19177C } /* Name.Variable */
.highlight .ow { color: #AA22FF; font-weight: bold } /* Operator.Word */
.highlight .w { color: #bbbbbb } /* Text.Whitespace */
.highlight .mf { color: #666666 } /* Literal.Number.Float */
.highlight .mh { color: #666666 } /* Literal.Number.Hex */
.highlight .mi { color: #666666 } /* Literal.Number.Integer */
.highlight .mo { color: #666666 } /* Literal.Number.Oct */
.highlight .sb { color: #BA2121 } /* Literal.String.Backtick */
.highlight .sc { color: #BA2121 } /* Literal.String.Char */
.highlight .sd { color: #BA2121; font-style: italic } /* Literal.String.Doc */
.highlight .s2 { color: #BA2121 } /* Literal.String.Double */
.highlight .se { color: #BB6622; font-weight: bold } /* Literal.String.Escape */
.highlight .sh { color: #BA2121 } /* Literal.String.Heredoc */
.highlight .si { color: #BB6688; font-weight: bold } /* Literal.String.Interpol */
.highlight .sx { color: #008000 } /* Literal.String.Other */
.highlight .sr { color: #BB6688 } /* Literal.String.Regex */
.highlight .s1 { color: #BA2121 } /* Literal.String.Single */
.highlight .ss { color: #19177C } /* Literal.String.Symbol */
.highlight .bp { color: #008000 } /* Name.Builtin.Pseudo */
.highlight .vc { color: #19177C } /* Name.Variable.Class */
.highlight .vg { color: #19177C } /* Name.Variable.Global */
.highlight .vi { color: #19177C } /* Name.Variable.Instance */
.highlight .il { color: #666666 } /* Literal.Number.Integer.Long */
</style>
</head>
<body>
<div class="document" id="a-simple-implementation-of-traits-for-python">
<h1 class="title">A simple implementation of traits for Python</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Michele Simionato</td></tr>
<tr><th class="docinfo-name">Date:</th>
<td>2009-01-10</td></tr>
<tr><th class="docinfo-name">Version:</th>
<td>0.5.1</td></tr>
<tr class="field"><th class="docinfo-name">Download:</th><td class="field-body"><a class="reference" href="http://pypi.python.org/pypi/strait">http://pypi.python.org/pypi/strait</a></td>
</tr>
<tr class="field"><th class="docinfo-name">Licence:</th><td class="field-body">BSD</td>
</tr>
</tbody>
</table>
<div class="abstract topic">
<p class="topic-title first">Abstract</p>
<p><em>I provide a simple implementation of
traits as units of composable behavior for Python. I
argue that traits are better than multiple inheritance.
Implementing frameworks based on traits is left as an exercise
for the reader.</em></p>
</div>
<div class="section">
<h1><a id="motivation" name="motivation">Motivation</a></h1>
<p>Multiple inheritance is a hotly debated topic.
The supporters of multiple inheritance
claim that it makes code shorter and easier
to read, whereas the opposers claim that is makes
code more coupled and more difficult to understand. I have
spent some time in the past facing the intricacies of <a class="reference" href="MRO">multiple
inheritance in Python</a> and I was one of its supporters once; however,
since then I have worked with frameworks making
large use of multiple inheritance (I mean Zope 2) and nowadays I am in
the number of the people who oppose it. Therefore I
am interested in alternatives.</p>
<p>In recent years, the approach
of <a class="reference" href="http://www.iam.unibe.ch/~scg/Research/Traits/">traits</a> has gained some traction in a few circles and I have
decided to write a library to implement traits in Python, for
experimentation purposes. The library is meant for framework builders,
people who are thinking about writing a framework based on multiple
inheritance - typically via the common mixin approach - but
are not convinced that this is the best solution and would like to try
an alternative. This library is also for authors of mixin-bases frameworks
which are unsatisfied and would like to convert their
framework to traits.</p>
<p>Are traits a better solution than multiple inheritance and mixins? In
theory I think so, otherwise I would not have written this library, but
in practice (as always) things may be different. It may well be
that using traits or using mixins does not make a big
difference in practice
and that the change of paradigm is not worth the effort; or the
opposite may be true. The only way to know is to try, to build
software based on traits and to see how it scale <em>in the large</em>.
In the small, more or less any approach works fine: it is only
by programming in the large that you can see the differences.</p>
<p>This is
the reason why I am releasing this library with a liberal licence, so
that people can try it out and see how it works. The library is meant
to play well (when possible) with pre-existing frameworks.
As an example, I will show
here how you could rewrite Tkinter classes to use traits instead of mixins. Of
course, I am not advocating rewriting Tkinter: it would be silly
and pointless; but it may have sense (or
not) to rewrite your own framework using traits, perhaps a framework
which is used in house but has not been released yet.</p>
<p>I am not the only one to have
implemented traits for Python; after finishing my implementation
I made a little research and discovered a few implementations. Then
I have also discovered the <a class="reference" href="https://svn.enthought.com/enthought/wiki/Traits">Enthought Traits</a> framework, which however
seems to use the name to intend something completely
different (i.e. a sort of type checking). My implementation has no
dependencies, is short and I am committed
to keep it short even in the future, according to
the principle of <a class="reference" href="http://www.artima.com/weblogs/viewpost.jsp?thread=236286">less is more</a>.</p>
<p>There is also an hidden agenda behind this module: to popularize some
advanced features of the Python object model which are little
known. The <tt class="docutils literal"><span class="pre">strait</span></tt> module is actually a tribute to the
metaprogramming capabilities of Python: such features are usually
associated to languages with a strong academic tradition - Smalltalk,
Scheme, Lisp - but actually the Python object model is no less
powerful. For instance, changing the object system from a multiple
inheritance one to a trait-based one,
can be done <em>within</em> the fundamental object system. The reason is that
the features that Guido used to implement the object system (special
method hooks, descriptors, metaclasses) are there, available to the
end user to build her own object system.</p>
<p>Such features are usually little used in the Python community, for
many good reasons: most people feel that the object system is good
enough and that there is no reason to change it; moreover there is
a strong opposition to change the language, because Python programmers
believe in uniformity and in using common idioms; finally, it is
difficult for an application programmer to find a domain where these
features are useful. An exception is the domain of the Object Relation
Mappers, whereas the Python language is often stretched to mimic the
SQL language, a famous example of this tendency being <a class="reference" href="http://www.sqlalchemy.org/">SQLAlchemy</a>).
Still, I have never seen a perversion of the object model as big as
the one implemented in the <tt class="docutils literal"><span class="pre">strait</span></tt> module, so I wanted to be the
first one to perform that kind of abuse ;)</p>
</div>
<div class="section">
<h1><a id="what-are-traits" name="what-are-traits">What are traits?</a></h1>
<p>The word <em>traits</em> has many meanings; I will refer to it in the sense
of the paper <a class="reference" href="http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf">Traits - Composable Units of Behavior</a> which implements
them in Squeak/Smalltalk. The paper appeared in 2003, but most of the
ideas underlying traits have been floating around for at least 30
years. There is also a trait implementation for <a class="reference" href="http://www.cs.utah.edu/plt/publications/aplas06-fff.pdf">PLT Scheme</a> which is
somewhat close in spirit (if not in practice) to what I am advocating here.
The library you are reading about is by no means intended as a porting
of the Smalltalk library: I am just stealing some of the ideas from
that paper to implement a Pythonic alternative to mixins which, for
lack of a better name, I have decided to call traits. I feel no
obligation whatsoever to be consistent with the Smalltalk library. In
doing so, I am following a long tradition, since a lot of languages
use the name <em>traits</em> to mean something completely different from the
Smalltalk meaning. For instance the languages Fortress and Scala use
the name <em>trait</em> but with a different meaning (Scala traits are very
close to multiple inheritance).
For me a trait is a bunch of methods and attributes with the following
properties:</p>
<ol class="arabic simple">
<li>the methods/attributes in a trait belong logically together;</li>
<li>if a trait enhances a class, then all subclasses are enhanced too;</li>
<li>if a trait has methods in common with the class, then the
methods defined in the class have the precedence;</li>
<li>the trait order is not important, i.e. enhancing a class
first with trait T1 and then with trait T2 or viceversa is the same;</li>
<li>if traits T1 and T2 have names in common, enhancing a class both
with T1 and T2 raises an error;</li>
<li>if a trait has methods in common with the base class, then the
trait methods have the precedence;</li>
<li>a class can be seen both as a composition of traits and as an homogeneous
entity.</li>
</ol>
<p>Properties from 4 to 7 are the distinguishing properties of traits
with respect to multiple inheritance and mixins. In particular,
because of 4 and 5, all the complications with the Method Resolution
Order disappear and the overriding is never implicit. Property 6 is
mostly unusual: typically in Python the base class has the precedence
over mixin classes. Property 7 should be intended in the sense that a
trait implementation must provide introspection facilities to make
seemless the transition between classes viewed as atomic entities and
as composed entities.</p>
</div>
<div class="section">
<h1><a id="a-hands-on-example" name="a-hands-on-example">A hands-on example</a></h1>
<p>Let me begin by showing how you could rewrite a
Tkinter class to use traits instead of mixins. Consider the
<tt class="docutils literal"><span class="pre">Tkinter.Widget</span></tt> class, which is derived by the base class
<tt class="docutils literal"><span class="pre">BaseWidget</span></tt> and the mixin classes
<tt class="docutils literal"><span class="pre">Tkinter.Grid</span></tt>, <tt class="docutils literal"><span class="pre">Tkinter.Pack</span></tt> and <tt class="docutils literal"><span class="pre">Tkinter.Place</span></tt>: I want to
rewrite it by using traits. The <tt class="docutils literal"><span class="pre">strait</span></tt> module
provides a factory function named <tt class="docutils literal"><span class="pre">include</span></tt> that does the job.
It is enough to replace the multiple inheritance syntax:</p>
<pre class="literal-block">
class Widget(BaseWidget, Grid, Pack, Place):
pass
</pre>
<p>with the following syntax:</p>
<pre class="literal-block">
class Widget(BaseWidget):
__metaclass__ = include(Pack, Place, Grid)
</pre>
<p>I said that the conversion from mixins to traits was easy: but actually
I lied since if you try to execute the code I just wrote you will
get an <tt class="docutils literal"><span class="pre">OverridingError</span></tt>:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; from Tkinter import *
&gt;&gt;&gt; class Widget(BaseWidget):
... __metaclass__ = include(Pack, Place, Grid)
Traceback (most recent call last):
...
OverridingError: Pack overrides names in Place: {info, config, configure,
slaves, forget}
</pre>
</blockquote>
<p>The reason for the error is clear: both <tt class="docutils literal"><span class="pre">Pack</span></tt> and <tt class="docutils literal"><span class="pre">Place</span></tt> provide
methods called <tt class="docutils literal"><span class="pre">{info,</span> <span class="pre">config,</span> <span class="pre">configure,</span> <span class="pre">slaves,</span> <span class="pre">forget}</span></tt>
and the traits implementation cannot figure out
which ones to use. This is a feature, since it forces you to be
explicit. In this case, if we want to be consistent with
multiple inheritance rules, we want the methods coming from
the first class (i.e. <tt class="docutils literal"><span class="pre">Pack</span></tt>) to take precedence. That can be
implemented by including directly those methods in the class namespace
and relying on rule 3:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">TOSWidget</span><span class="p">(</span><span class="n">BaseWidget</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">include</span><span class="p">(</span><span class="n">Pack</span><span class="p">,</span> <span class="n">Place</span><span class="p">,</span> <span class="n">Grid</span><span class="p">)</span>
<span class="n">info</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">info</span><span class="o">.</span><span class="n">im_func</span>
<span class="n">config</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">config</span><span class="o">.</span><span class="n">im_func</span>
<span class="n">configure</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">configure</span><span class="o">.</span><span class="n">im_func</span>
<span class="n">slaves</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">slaves</span><span class="o">.</span><span class="n">im_func</span>
<span class="n">forget</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">forget</span><span class="o">.</span><span class="n">im_func</span>
<span class="n">propagate</span> <span class="o">=</span> <span class="n">Pack</span><span class="o">.</span><span class="n">propagate</span><span class="o">.</span><span class="n">im_func</span>
</pre></div>
</div>
<p>Notice that we had to specify the <tt class="docutils literal"><span class="pre">propagate</span></tt> method too, since
it is a common method between <tt class="docutils literal"><span class="pre">Pack</span></tt> and <tt class="docutils literal"><span class="pre">Grid</span></tt>.</p>
<p>You can check that the TOSWidget class works, for instance by defining a
label widget as follows (remember that <tt class="docutils literal"><span class="pre">TOSWidget</span></tt> inherits its signature
from <tt class="docutils literal"><span class="pre">BaseWidget</span></tt>):</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; label = TOSWidget(master=None, widgetName='label',
... cnf=dict(text=&quot;hello&quot;))
</pre>
</blockquote>
<p>You may visualize the widget by calling the <tt class="docutils literal"><span class="pre">.pack</span></tt> method:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; label.pack()
</pre>
</blockquote>
<p>This should open a small window with the message &quot;hello&quot; inside it.</p>
</div>
<div class="section">
<h1><a id="a-few-caveats-and-warnings" name="a-few-caveats-and-warnings">A few caveats and warnings</a></h1>
<p>First of all, let me notice that, in spite of apparency, <tt class="docutils literal"><span class="pre">include</span></tt>
does not return a metaclass. Insted, it returns a class factory
function with signature <tt class="docutils literal"><span class="pre">name,</span> <span class="pre">bases,</span> <span class="pre">dic</span></tt>:</p>
<pre class="doctest-block">
&gt;&gt;&gt; print include(Pack, Place, Grid)
&lt;function include_Pack_Place_Grid at 0x...&gt;
</pre>
<p>This function will create the class by using a suitable
metaclass:</p>
<pre class="doctest-block">
&gt;&gt;&gt; type(TOSWidget)
&lt;class 'strait.MetaTOS'&gt;
</pre>
<p>In simple cases the metaclass will be <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>, the main class
of the trait object system, but in general it can be a different
one not inheriting from <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>. The exact rules followed by
<tt class="docutils literal"><span class="pre">include</span></tt> to determine the right class will be discussed later.</p>
<p>Here I want to remark that according to rule 6 traits take the precedence
over the base class attributes. Consider the following example:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; class Base(object):
... a = 1
</pre>
<pre class="doctest-block">
&gt;&gt;&gt; class ATrait(object):
... a = 2
</pre>
<pre class="doctest-block">
&gt;&gt;&gt; class Class(Base):
... __metaclass__ = include(ATrait)
</pre>
<pre class="doctest-block">
&gt;&gt;&gt; Class.a
2
</pre>
</blockquote>
<p>In regular multiple inheritance you would do the same by including
<tt class="docutils literal"><span class="pre">ATrait</span></tt> <em>before</em> <tt class="docutils literal"><span class="pre">Base</span></tt>, i.e.</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; type('Class', (ATrait, Base), {}).a
2
</pre>
</blockquote>
<p>You should take care to not mix-up the order, otherwise you will get a
different result:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; type('Class', (Base, ATrait), {}).a
1
</pre>
</blockquote>
<p>Therefore replacing mixin classes with traits can break your code if
you rely on the order. Be careful!</p>
</div>
<div class="section">
<h1><a id="the-trait-object-system" name="the-trait-object-system">The Trait Object System</a></h1>
<p>The goal of the <tt class="docutils literal"><span class="pre">strait</span></tt> module it to modify the standard
Python object model, turning it into a Trait Object System (TOS for short):
TOS classes behave differently from regular
classes. In particular TOS classes do not support multiple inheritance.
If you try to multiple inherit from a TOS
class and another class you will get a <tt class="docutils literal"><span class="pre">TypeError</span></tt>:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; class M:
... &quot;An empty class&quot;
...
&gt;&gt;&gt; class Widget2(TOSWidget, M):
... pass
...
Traceback (most recent call last):
...
TypeError: Multiple inheritance of bases (&lt;class '__main__.TOSWidget'&gt;, &lt;class
__main__.M at 0x...&gt;) is forbidden for TOS classes
</pre>
</blockquote>
<p>This behavior is intentional: with this restriction you can simulate
an ideal world in which Python did not support multiple
inheritance. Suppose you want to claim that supporting multiple
inheritance was a mistake and that Python would have been better off
without it (which is the position I tend to have nowadays): how can
you prove that claim? Simply by writing code that does not use
multiple inheritance and it is clearer and more mantainable that code
using multiple inheritance.</p>
<p>I am releasing this trait implementation hoping you will help me to
prove (or possibly disprove) the point. You may see traits as a
restricted form of multiple inheritance without name clashes,
without the complications of the method resolution, and with a
limited cooperation between methods.
Moreover the present implementation is slightly less dynamic
than usual inheritance.</p>
<p>A nice property of inheritance is that if you have a class <tt class="docutils literal"><span class="pre">C</span></tt> inheriting
from class <tt class="docutils literal"><span class="pre">M</span></tt> and you change a method in <tt class="docutils literal"><span class="pre">M</span></tt> at runtime, after
<tt class="docutils literal"><span class="pre">C</span></tt> has been created and instantiated, automagically all instances
of <tt class="docutils literal"><span class="pre">C</span></tt> gets the new version of the method, which is pretty useful
for debugging purposes. This feature is lost in the trait implementation
provided here. Actually, in a previous version, my trait implementation
was fully dynamic and if you changed the mixin the instances would be
changed too. However, I never used that feature in practice, and
it was complicating the implementation and slowing doing the
attribute access, so I removed it.</p>
<p>I think these are acceptable restrictions since they give back
in return many advantages in terms of simplicity: for instance,
<tt class="docutils literal"><span class="pre">super</span></tt> becomes trivial, since each class has a single superclass,
whereas we all know that the <a class="reference" href="http://www.artima.com/weblogs/viewpost.jsp?thread=236275">current super in Python</a> is very far
from trivial.</p>
</div>
<div class="section">
<h1><a id="the-magic-of-include" name="the-magic-of-include">The magic of <tt class="docutils literal"><span class="pre">include</span></tt></a></h1>
<p>Since the fundamental properties of TOS classes must be preserved under
inheritance (i.e. the son of a TOS class must be a TOS class)
the implementation necessarily requires metaclasses. As of now,
the only fundamental property of a TOS class is that multiple
inheritance is forbidden, so usually (<em>but not always</em>) TOS
classes are instances of the metaclass <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>
which implements a single inheritance check.
If you build your TOS hierarchy starting from pre-existing classes,
you should be aware of how <tt class="docutils literal"><span class="pre">include</span></tt> determines the metaclass:
if your base class was an old-style
class or a plain new style class (i.e. a direct instance of the
<tt class="docutils literal"><span class="pre">type</span></tt> metaclass), them <tt class="docutils literal"><span class="pre">include</span></tt> will change it to <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>:</p>
<pre class="doctest-block">
&gt;&gt;&gt; type(TOSWidget)
&lt;class 'strait.MetaTOS'&gt;
</pre>
<p>In general you may need to build your Trait Based Framework
on top of pre-existing classes possessing a nontrivial metaclass, for
instance Zope classes; in that case <tt class="docutils literal"><span class="pre">include</span></tt> is smart
enough to figure out the right metaclass to use. Here is an example:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">AddGreetings</span><span class="p">(</span><span class="nb">type</span><span class="p">):</span>
<span class="s">&quot;A metaclass adding a &#39;greetings&#39; attribute for exemplification purposes&quot;</span>
<span class="k">def</span> <span class="nf">__new__</span><span class="p">(</span><span class="n">mcl</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">bases</span><span class="p">,</span> <span class="n">dic</span><span class="p">):</span>
<span class="n">dic</span><span class="p">[</span><span class="s">&#39;greetings&#39;</span><span class="p">]</span> <span class="o">=</span> <span class="s">&#39;hello!&#39;</span>
<span class="k">return</span> <span class="nb">super</span><span class="p">(</span><span class="n">AddGreetings</span><span class="p">,</span> <span class="n">mcl</span><span class="p">)</span><span class="o">.</span><span class="n">__new__</span><span class="p">(</span><span class="n">mcl</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">bases</span><span class="p">,</span> <span class="n">dic</span><span class="p">)</span>
</pre></div>
</div>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">WidgetWithGreetings</span><span class="p">(</span><span class="n">BaseWidget</span><span class="p">,</span> <span class="nb">object</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">AddGreetings</span>
</pre></div>
</div>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">PackWidget</span><span class="p">(</span><span class="n">WidgetWithGreetings</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">include</span><span class="p">(</span><span class="n">Pack</span><span class="p">)</span>
</pre></div>
</div>
<p><tt class="docutils literal"><span class="pre">include</span></tt> automatically generates the right metaclass as
a subclass of <tt class="docutils literal"><span class="pre">AddGreetings</span></tt>:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; print type(PackWidget).__mro__
(&lt;class 'strait._TOSAddGreetings'&gt;, &lt;class '__main__.AddGreetings'&gt;, &lt;type
'type'&gt;, &lt;type 'object'&gt;)
</pre>
</blockquote>
<p>Incidentally, since TOS
classes are guaranteed to be in a straight hierarchy, <tt class="docutils literal"><span class="pre">include</span></tt> is able
to neatly avoid the dreaded <a class="reference" href="http://code.activestate.com/recipes/204197/">metaclass conflict</a>.</p>
<p>The important point is that <tt class="docutils literal"><span class="pre">_TOSAddGreetings</span></tt> provides the same features of
<tt class="docutils literal"><span class="pre">MetaTOS</span></tt>, even if it is not a subclass of it; on the
other hand, <tt class="docutils literal"><span class="pre">_TOSMetaAddGreetings</span></tt> is a subclass of <tt class="docutils literal"><span class="pre">AddGreetings</span></tt>
which calls <tt class="docutils literal"><span class="pre">AddGreetings.__new__</span></tt>, so the features provided by
<tt class="docutils literal"><span class="pre">AddGreetings</span></tt> are not lost either; in this example you may check
that the greetings attribute is correctly set:</p>
<blockquote>
<pre class="doctest-block">
&gt;&gt;&gt; PackWidget.greetings
'hello!'
</pre>
</blockquote>
<p>The name of the generated metaclass
is automatically generated from the name of the base
metaclass; moreover, a register of the generated metaclasses
is kept, so that metaclasses are reused if possible.
If you want to understand the details, you are welcome
to give a look at the implementation, which is pretty short
and simple, compared to the general recipe to remove
the metaclass conflict in a true multiple inheritance situation.</p>
</div>
<div class="section">
<h1><a id="cooperative-traits" name="cooperative-traits">Cooperative traits</a></h1>
<p>At first sight, the Trait Object System lacks an important feature of
multiple inheritance as implemented in the ordinary Python object system,
i.e. cooperative methods. Consider for instance the following
classes:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">LogOnInitMI</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">):</span>
<span class="k">print</span> <span class="s">&#39;Initializing </span><span class="si">%s</span><span class="s">&#39;</span> <span class="o">%</span> <span class="bp">self</span>
<span class="nb">super</span><span class="p">(</span><span class="n">LogOnInitMI</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span><span class="n">__init__</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">)</span>
</pre></div>
</div>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">RegisterOnInitMI</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="n">register</span> <span class="o">=</span> <span class="p">[]</span>
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">):</span>
<span class="k">print</span> <span class="s">&#39;Registering </span><span class="si">%s</span><span class="s">&#39;</span> <span class="o">%</span> <span class="bp">self</span>
<span class="bp">self</span><span class="o">.</span><span class="n">register</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span>
<span class="nb">super</span><span class="p">(</span><span class="n">RegisterOnInitMI</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span><span class="n">__init__</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">)</span>
</pre></div>
</div>
<p>In multiple inheritance <tt class="docutils literal"><span class="pre">LogOnInitMI</span></tt> can be mixed with other
classes, giving to the children the ability to log on initialization;
the same is true for <tt class="docutils literal"><span class="pre">RegisterOnInitMI</span></tt>, which gives to its children
the ability to populate a registry of instances. The important feature
of the multiple inheritance system is that <tt class="docutils literal"><span class="pre">LogOnInitMI</span></tt> and
<tt class="docutils literal"><span class="pre">RegisterOnInitMI</span></tt> play well together: if you inherits from
both of them, you get both features:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">C_MI</span><span class="p">(</span><span class="n">LogOnInitMI</span><span class="p">,</span> <span class="n">RegisterOnInitMI</span><span class="p">):</span>
<span class="k">pass</span>
</pre></div>
</div>
<pre class="doctest-block">
&gt;&gt;&gt; c = C_MI()
Initializing &lt;__main__.C_MI object at 0x...&gt;
Registering &lt;__main__.C_MI object at 0x...&gt;
</pre>
<p>You cannot get the same behaviour if you use the trait object system
naively:</p>
<pre class="doctest-block">
&gt;&gt;&gt; class C_MI(object):
... __metaclass__ = include(LogOnInitMI, RegisterOnInitMI)
...
Traceback (most recent call last):
...
OverridingError: LogOnInitMI overrides names in RegisterOnInitMI: {__init__}
</pre>
<p>This is a feature, of course, since the trait object system is designed
to avoid name clashes. However, the situation is worse than that:
even if you try to mixin a single class you will run into trouble</p>
<pre class="doctest-block">
&gt;&gt;&gt; class C_MI(object):
... __metaclass__ = include(LogOnInitMI)
</pre>
<pre class="doctest-block">
&gt;&gt;&gt; c = C_MI()
Traceback (most recent call last):
...
TypeError: super(type, obj): obj must be an instance or subtype of type
</pre>
<p>What's happening here? The situation is clear if you notice that the
<tt class="docutils literal"><span class="pre">super</span></tt> call is actually a call of kind <tt class="docutils literal"><span class="pre">super(LogOnInitMI,</span> <span class="pre">c)</span></tt>
where <tt class="docutils literal"><span class="pre">c</span></tt> is an instance of <tt class="docutils literal"><span class="pre">C</span></tt>, which is not a
subclass of <tt class="docutils literal"><span class="pre">LogOnInitMI</span></tt>. That explains the
error message, but does not explain how to solve the issue. It seems
that method cooperation using <tt class="docutils literal"><span class="pre">super</span></tt> is impossible for TOS
classes.</p>
<p>Actually this is not the case: single inheritance cooperation
is possible and it is enough as we will show in a
minute. But for the moment let me notice that I do not think
that cooperative methods are necessarily a good idea. They are
fragile and cause all of your classes to be strictly coupled. My usual
advice if that you should not use a design based on method
cooperation if you can avoid it.
Having said that, there are situations (very rare) where you
really want method cooperation. The <tt class="docutils literal"><span class="pre">strait</span></tt> module provide
support for those situations via the <tt class="docutils literal"><span class="pre">__super</span></tt> attribute.</p>
<p>Let me explain how it works. When you mix-in a trait <tt class="docutils literal"><span class="pre">T</span></tt> into a
class <tt class="docutils literal"><span class="pre">C</span></tt>, <tt class="docutils literal"><span class="pre">include</span></tt> adds an attribute <tt class="docutils literal"><span class="pre">_T__super</span></tt> to <tt class="docutils literal"><span class="pre">C</span></tt>,
which is a <tt class="docutils literal"><span class="pre">super</span></tt> object that dispatches to the attributes of the
superclass of <tt class="docutils literal"><span class="pre">C</span></tt>. The important thing to keep in mind is that there
is a well defined superclass, since the trait object system uses
single inheritance only. Since the hierarchy is straight, the
cooperation mechanism is much simpler to understand than in multiple
inheritance. Here is an example. First of all, let me rewrite
<tt class="docutils literal"><span class="pre">LogOnInit</span></tt> and <tt class="docutils literal"><span class="pre">RegisterOnInit</span></tt> to use <tt class="docutils literal"><span class="pre">__super</span></tt> instead of
<tt class="docutils literal"><span class="pre">super</span></tt>:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">LogOnInit</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">):</span>
<span class="k">print</span> <span class="s">&#39;Initializing </span><span class="si">%s</span><span class="s">&#39;</span> <span class="o">%</span> <span class="bp">self</span>
<span class="bp">self</span><span class="o">.</span><span class="n">__super</span><span class="o">.</span><span class="n">__init__</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">)</span>
</pre></div>
</div>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">RegisterOnInit</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="n">register</span> <span class="o">=</span> <span class="p">[]</span>
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">):</span>
<span class="k">print</span> <span class="s">&#39;Registering </span><span class="si">%s</span><span class="s">&#39;</span> <span class="o">%</span> <span class="bp">self</span>
<span class="bp">self</span><span class="o">.</span><span class="n">register</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">__super</span><span class="o">.</span><span class="n">__init__</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">)</span>
</pre></div>
</div>
<p>Now you can include the <tt class="docutils literal"><span class="pre">RegisterOnInit</span></tt> functionality as follows:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">C_Register</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">include</span><span class="p">(</span><span class="n">RegisterOnInit</span><span class="p">)</span>
</pre></div>
</div>
<pre class="doctest-block">
&gt;&gt;&gt; _ = C_Register()
Registering &lt;__main__.C_Register object at 0x...&gt;
</pre>
<p>Everything works because <tt class="docutils literal"><span class="pre">include</span></tt> has added the right attribute:</p>
<pre class="doctest-block">
&gt;&gt;&gt; C_Register._RegisterOnInit__super
&lt;super: &lt;class 'C_Register'&gt;, &lt;C_Register object&gt;&gt;
</pre>
<p>Moreover, you can also include the <tt class="docutils literal"><span class="pre">LogOnInit</span></tt> functionality:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">C_LogAndRegister</span><span class="p">(</span><span class="n">C_Register</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">include</span><span class="p">(</span><span class="n">LogOnInit</span><span class="p">)</span>
</pre></div>
</div>
<pre class="doctest-block">
&gt;&gt;&gt; _ = C_LogAndRegister()
Initializing &lt;__main__.C_LogAndRegister object at 0x...&gt;
Registering &lt;__main__.C_LogAndRegister object at 0x...&gt;
</pre>
<p>As you see, the cooperation mechanism works just fine. I will call
<em>cooperative trait</em> a class intended for inclusion in other classes
and making use of the <tt class="docutils literal"><span class="pre">__super</span></tt> trick. A class using the
regular <tt class="docutils literal"><span class="pre">super</span></tt> directly cannot be used as a cooperative trait, since it
must satisfy inheritance constraints, nevertherless it is easy enough to
convert it to use <tt class="docutils literal"><span class="pre">__super</span></tt>. After all, the <tt class="docutils literal"><span class="pre">strait</span></tt> module is
intended for framework writers, so it assumes you can change the
source code of your framework if you want. On the other hand, if
are trying to re-use a mixin class coming from a third party
framework and using <tt class="docutils literal"><span class="pre">super</span></tt>, you will have to rewrite the
parts of it. That is unfortunate, but I cannot perform miracles.</p>
<p>You may see <tt class="docutils literal"><span class="pre">__super</span></tt> as a clever hack to use
<tt class="docutils literal"><span class="pre">super</span></tt> indirectly. Notice that since the hierarchy is straight,
there is room for optimization at the core language
level. The <tt class="docutils literal"><span class="pre">__super</span></tt> trick as implemented in pure Python leverages
on the name mangling mechanism, and follows closely the famous
<a class="reference" href="http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_examples">autosuper recipe</a>, with some improvement. Anyway,
if you have two traits with the same
name, you will run into trouble. To solve this and to have a nicer
syntax, one would need more support from the language, but the
<tt class="docutils literal"><span class="pre">__super</span></tt> trick is good enough for a prototype and
has the serious advantage of working right now for current Python.</p>
</div>
<div class="section">
<h1><a id="cooperation-at-the-metaclass-level" name="cooperation-at-the-metaclass-level">Cooperation at the metaclass level</a></h1>
<p>In my experience, the cases where you need method cooperation
in multiple inheritance situations are exceedingly rare,
unless you are a language implementor or a designer of
very advanced frameworks. In such a realm you have a need for
cooperative methods; it is not a pressing need, in the sense that
you can always live without them, but they are a nice feature to have if you
care about elegance and extensibility. For instance, as P. J. Eby
points it out in this <a class="reference" href="http://www.gossamer-threads.com/lists/python/dev/673833">thread on python-dev</a>:</p>
<p><em>A major use case for co-operative super() is in the implementation of
metaclasses. The __init__ and __new__ signatures are fixed, multiple
inheritance is possible, and co-operativeness is a must (as the base
class methods</em> must <em>be called). I'm hard-pressed to think of a
metaclass constructor or initializer that I've written in the last
half-decade or more where I didn't use super() to make it
co-operative. That, IMO, is a compelling use case even if there were
not a single other example of the need for super.</em></p>
<p>I have always felt the same. So, even if I have been unhappy with multiple
inheritance for years, I could never dismiss it entirely
because of the concern for this use case. It is only after discovering
cooperative traits that I felt the approach powerful enough
to replace multiple inheritance without losing anything I cared about.</p>
<p>Multiple inheritance at the metaclass level comes out here and
again when you are wearing the language implementor hat. For instance,
if you try to implement an object system based on traits, you will have to do
so at the metaclass level and there method cooperation has its place.
In particular, if you look at the source code of the <tt class="docutils literal"><span class="pre">strait</span></tt> module -
which is around 100 lines, a tribute to the power of Python -
you will see that the <tt class="docutils literal"><span class="pre">MetaTOS</span></tt> metaclass is implemented
as a cooperative trait, so that it can be mixed-in with other metaclasses,
in the case you are interoperating with a framework with a non-trivial
meta object protocol. This is performed internally by <tt class="docutils literal"><span class="pre">include</span></tt>.</p>
<p>Metaclass cooperation is there to make the life of the users
easier. Suppose one of you, users of the <tt class="docutils literal"><span class="pre">strait</span></tt> module, wants to
enhance the <tt class="docutils literal"><span class="pre">include</span></tt> mechanism using another a metaclass coming for
a third party framework and therefore not inheriting from <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">ThirdPartyMeta</span><span class="p">(</span><span class="nb">type</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">__new__</span><span class="p">(</span><span class="n">mcl</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">bases</span><span class="p">,</span> <span class="n">dic</span><span class="p">):</span>
<span class="k">print</span> <span class="s">&#39;Using ThirdPartyMeta to create </span><span class="si">%s</span><span class="s">&#39;</span> <span class="o">%</span> <span class="n">name</span>
<span class="k">return</span> <span class="nb">super</span><span class="p">(</span><span class="n">ThirdPartyMeta</span><span class="p">,</span> <span class="n">mcl</span><span class="p">)</span><span class="o">.</span><span class="n">__new__</span><span class="p">(</span><span class="n">mcl</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">bases</span><span class="p">,</span> <span class="n">dic</span><span class="p">)</span>
</pre></div>
</div>
<p>The way to go is simple. First, you should mix-in <tt class="docutils literal"><span class="pre">MetaTOS</span></tt> in the
third party class:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">class</span> <span class="nc">EnhancedMetaTOS</span><span class="p">(</span><span class="n">ThirdPartyMeta</span><span class="p">):</span>
<span class="n">__metaclass__</span> <span class="o">=</span> <span class="n">include</span><span class="p">(</span><span class="n">MetaTOS</span><span class="p">)</span>
</pre></div>
</div>
<p>Then, you can define your own enhanced <tt class="docutils literal"><span class="pre">include</span></tt> as follows:</p>
<div class="codeblock python">
<div class="highlight"><pre><span class="k">def</span> <span class="nf">enhanced_include</span><span class="p">(</span><span class="o">*</span><span class="n">traits</span><span class="p">):</span>
<span class="k">return</span> <span class="n">include</span><span class="p">(</span><span class="n">MetaTOS</span><span class="o">=</span><span class="n">EnhancedMetaTOS</span><span class="p">,</span> <span class="o">*</span><span class="n">traits</span><span class="p">)</span>
</pre></div>
</div>
<p>In simple cases using directly <tt class="docutils literal"><span class="pre">ThirdPartyMeta</span></tt> may work, but I strongly
recommend to replace the call to super with <tt class="docutils literal"><span class="pre">__super</span></tt> even in
<tt class="docutils literal"><span class="pre">ThirdPartyMeta</span></tt> to make the cooperation robust.</p>
</div>
<div class="section">
<h1><a id="discussion-of-some-design-decisions-and-future-work" name="discussion-of-some-design-decisions-and-future-work">Discussion of some design decisions and future work</a></h1>
<p>The decision of having TOS classes which are not instances of
<tt class="docutils literal"><span class="pre">MetaTOS</span></tt>
required some thought. That was my original idea in version 0.1 of
<tt class="docutils literal"><span class="pre">strait</span></tt>; however in version 0.2 I wanted to see what would happen
if I made all TOS classes instances of <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>.
That implied that if
your original class had a nontrivial metaclass, then the TOS class had
to inherit both from the original metaclass <em>and</em> <tt class="docutils literal"><span class="pre">MetaTOS</span></tt>,
i.e. multiple inheritance and cooperation of methods was required at
the metaclass level.</p>
<p>I did not like it, since I was arguing that
you can do everything without multiple inheritance; moreover using
multiple inheritance at the metaclass level
meant that one had to solve the metaclass conflict in a general
way. I did so, by using my own cookbook recipe, and all my tests
passed.</p>
<p>Neverthess, at the end, in version 0.3 I decided to go back to the
original design. The metaclass conflict recipe is too complex, and I
see it as a code smell - <em>if the implementation is hard to explain,
it's a bad idea</em> - just another indication that multiple inheritance
is bad. In the original design it is possible to add the features of
<tt class="docutils literal"><span class="pre">MetaTOS</span></tt> to the original metaclass by subclassing it with <em>single</em>
inheritance and thus avoiding the conflict.</p>
<p>The price to pay is that now a TOS class is no more an instance of
<tt class="docutils literal"><span class="pre">MetaTOS</span></tt>, but this is a non-issue: the important
thing is that TOS classes perform the dispatch on their traits as
<tt class="docutils literal"><span class="pre">MetaTOS</span></tt> would dictate. Moreover, starting from
Python 2.6, thanks to <a class="reference" href="http://www.python.org/dev/peps/pep-3119/">Abstract Base Classes</a>, you may satisfy the
<tt class="docutils literal"><span class="pre">isinstance(obj,</span> <span class="pre">cls)</span></tt> check even if <tt class="docutils literal"><span class="pre">obj</span></tt> is not an instance of
<tt class="docutils literal"><span class="pre">cls</span></tt>, by registering a suitable base class (similarly for
<tt class="docutils literal"><span class="pre">issubclass</span></tt>). In our situation, that means that it is enough to
register <tt class="docutils literal"><span class="pre">MetaTOS</span></tt> as base class of the original
metaclass.</p>
<p>Version 0.4 was much more complex that the current version (still
short, it was under 300 lines of pure Python), since it had the more
ambitious goal of solving the namespace pollution problem. I have
discussed the issue <a class="reference" href="http://www.artima.com/weblogs/viewpost.jsp?thread=246341">elsewhere</a>: if you keep injecting methods into a
class (both directly or via inheritance) you may end up having
hundreds of methods flattened at the same level.</p>
<p>A picture is worth a
thousand words, so have a look at the <a class="reference" href="http://www.phyast.pitt.edu/~micheles/python/plone-hierarchy.png">PloneSite hierarchy</a> if you
want to understand the horror I wanted to avoid with traits (the
picture shows the number of nonspecial attributes defined per class in
square brackets): in the Plone Site hierarchy there are 38 classes, 88
overridden names, 42 special names, 648 non-special attributes and
methods. It is a nighmare.</p>
<p>Originally I wanted to prevent this kind
of abuse, but that made my implementation more complex, whereas
my main goal was to keep the implementation simple. As a consequence
this version assume the prosaic attitude that you cannot stop
programmers from bad design anyway, so if they want to go the Zope
way they can.</p>
<p>In previous versions I did provide some syntactic sugar for <tt class="docutils literal"><span class="pre">include</span></tt>
so that it was possible to write something like the following
(using a trick discussed <a class="reference" href="http://www.ibm.com/developerworks/linux/library/l-pymeta3.html">here</a>):</p>
<pre class="literal-block">
class C(Base):
include(Trait1, Trait2)
</pre>
<p>In version 0.5 I decided to remove this feature. Now the plumbing
(i.e. the <tt class="docutils literal"><span class="pre">__metaclass__</span></tt> hook) is exposed to the user, some magic
has been removed and it is easier for the user to write her own
<tt class="docutils literal"><span class="pre">include</span></tt> factory if she wants to.</p>
<p>Where to go from here? For the moment, I have no clear idea about the
future. The Smalltalk implementation of traits provides method
renaming out of the box. The Python implementation has no facilities
in this sense. In the future I may decide to give some support for
renaming, or I may not. At the present you can just rename your
methods by hand. Also, in the future I may decide to add some kind of
adaptation mechanism or I may not: after all the primary goal of this
implementation is semplicity and I don't want to clutter it with too
many features.</p>
<p>I am very open to feedback and criticism: I am releasing this module
with the hope that it will be used in real life situations to gather
experience with the traits concept. Clearly I am not proposing that
Python should remove multiple inheritance in favor of traits:
considerations of backward compatibily would kill the proposal right
from the start. I am just looking for a few adventurous volunteers
wanting to experiment with traits; if the experiment goes well, and
people start using (multiple) inheritance less than they do now, I
will be happy.</p>
</div>
<div class="section">
<h1><a id="trivia" name="trivia">Trivia</a></h1>
<p><tt class="docutils literal"><span class="pre">strait</span></tt> officially stands for Simple Trait object system, however
the name is also a pun on the world &quot;straight&quot;, since the difference
between multiple inheritance hierarchies and TOS hierarchies is that
TOS hierarchies are straight. Moreover, nobody will stop you from
thinking that the <tt class="docutils literal"><span class="pre">s</span></tt> also stands for Simionato ;)</p>
</div>
</div>
<div class="footer">
<hr class="footer" />
<a class="reference" href="docs.rst">View document source</a>.
Generated on: 2009-01-10 10:52 UTC.
Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
</div>
</body>
</html>
<pre>Michele Simionatoab893da5395b555f05aea49f8d6fd4378261e15f0.5.1