Commit c0e94fad authored by Andreas Jung's avatar Andreas Jung

changes to broken handling of __literals__ required refreshed

reference files
parent 79c8d8ad
......@@ -55,7 +55,7 @@
that performs attribute lookup in <code>c</code> when an attribute
cannot be found in <code>a</code>.</p>
<p> Aquisition wrappers provide access to the wrapped objects
through the attributes 'aq<u>parent', 'aq</u>self', <code>aq_base</code>.
through the attributes <code>aq_parent</code>, <code>aq_self</code>, <code>aq_base</code>.
In the example above, the expressions:
<pre>
'c.a.aq_parent is c'
......@@ -73,8 +73,8 @@
</p>
<p> evaluates to false, because the expression <code>c.a</code> evaluates
to an acquisition wrapper around <code>c</code> and <code>a</code>, not <code>a</code> itself.</p>
<p> The attribute 'aq<u>base' is similar to 'aq</u>self'. Wrappers may be
nested and 'aq<u>self' may be a wrapped object. The 'aq</u>base'
<p> The attribute <code>aq_base</code> is similar to <code>aq_self</code>. Wrappers may be
nested and <code>aq_self</code> may be a wrapped object. The <code>aq_base</code>
attribute is the underlying object with all wrappers removed.</p>
<h2> Acquisition Control</h2>
<p> Two styles of acquisition are supported in the current
......@@ -117,8 +117,8 @@
</pre>
</p>
<p> The <em>only</em> attributes that are automatically acquired from
containing objects are <code>color</code>, and '_<u>roles</u><u><code>. Note also
that the </code></u><u>roles</u>_' attribute is acquired even though it's
containing objects are <code>color</code>, and <code>__roles__</code>. Note also
that the <code>__roles__</code> attribute is acquired even though it's
name begins with an underscore. In fact, the special
<code>Acquisition.Acquired</code> value can be used in
<code>Acquisition.Implicit</code> objects to implicitly acquire selected
......@@ -232,23 +232,23 @@
would have failed.</p>
<p> If desired, the current rules for looking up attributes in complex
expressions can best be understood through repeated application of
the '_<u>of</u>_' method:</p>
the <code>__of__</code> method:</p>
<dl>
<dt> <code>a.x</code></dt>
<dd>'x._<u>of</u>_(a)'</dd>
<dd><code>x.__of__(a)</code></dd>
<dt> <code>a.b</code></dt>
<dd>'b._<u>of</u>_(a)'</dd>
<dd><code>b.__of__(a)</code></dd>
<dt> <code>a.b.x</code></dt>
<dd>'x._<u>of</u><u>(a).</u><u>of</u><u>(b.</u><u>of</u>_(a))'</dd>
<dd><code>x.__of__(a).__of__(b.__of__(a))</code></dd>
<dt> <code>a.b.c</code></dt>
<dd>'c._<u>of</u><u>(b.</u><u>of</u>_(a))'</dd>
<dd><code>c.__of__(b.__of__(a))</code></dd>
<dt> <code>a.b.c.x</code></dt>
<dd>'x._<u>of</u><u>(a).</u><u>of</u><u>(b.</u><u>of</u><u>(a)).</u><u>of</u><u>(c.</u><u>of</u><u>(b.</u><u>of</u>_(a)))'</dd>
<dd><code>x.__of__(a).__of__(b.__of__(a)).__of__(c.__of__(b.__of__(a)))</code></dd>
</dl>
<p> and by keeping in mind that attribute lookup in a wrapper
is done by trying to lookup the attribute in the wrapped object
first and then in the parent object. In the expressions above
involving the '_<u>of</u>_' method, lookup proceeds from left to right.</p>
involving the <code>__of__</code> method, lookup proceeds from left to right.</p>
<p> Note that heuristics are used to avoid most of the repeated
lookups. For example, in the expression: <code>a.b.c.x.foo</code>, the object
<code>a</code> is searched no more than once, even though it is wrapped three
......
......@@ -32,7 +32,7 @@
to implement "synchonized" classes and could be used to
implement argument type checking.</p></li>
<li><p>A protocol for class initialization that supports execution of a
special '_<u>class</u>init__' method after a class has been
special <code>__class_init__</code> method after a class has been
initialized. </p></li>
</ul>
......@@ -80,10 +80,10 @@
slightly different than the usual class and instance semantics,
yet we don't want to do most of our development in C. For
example, we have developed a persistence mechanism <a href="#1">[1]</a> that
redefines '_<u>getattr</u><u><code> and </code></u><u>setattr</u>_' to take storage-related
redefines <code>__getattr__</code> and <code>__setattr__</code> to take storage-related
actions when object state is accessed or modified. We want to be
able to take certain actions on <em>every</em> attribute reference, but
for python class instances, '_<u>getattr</u>_' is only called when
for python class instances, <code>__getattr__</code> is only called when
attribute lookup fails by normal means.</p>
<p> As another example, we would like to have greater control over how
methods are bound. Currently, when accessing a class
......@@ -196,15 +196,15 @@
<p> Like standard python classes, extension classes have the following
attributes containing meta-data:</p>
<dl>
<dt> '_<u>doc</u>_'</dt>
<dt> <code>__doc__</code></dt>
<dd>a documentation string for the class,</dd>
<dt> '_<u>name</u>_'</dt>
<dt> <code>__name__</code></dt>
<dd>the class name,</dd>
<dt> '_<u>bases</u>_'</dt>
<dt> <code>__bases__</code></dt>
<dd>a sequence of base classes,</dd>
<dt> '_<u>dict</u>_'</dt>
<dt> <code>__dict__</code></dt>
<dd>a class dictionary, and</dd>
<dt> '_<u>module</u>_'</dt>
<dt> <code>__module__</code></dt>
<dd>the name of the module in which the class was
defined. </dd>
</dl>
......@@ -240,7 +240,7 @@
<code>ExtensionClass.h</code> that converts a method list to a method chain.
(See the example below.)</p></li>
<li><p>Module functions that create new instances must be replaced by
'_<u>init</u>_' methods that initialize, but does not create storage for
<code>__init__</code> methods that initialize, but does not create storage for
instances.</p></li>
<li><p>The extension class must be initialized and exported to the module
with:
......@@ -264,9 +264,9 @@
</pre>
</p>
<p> where <code>name</code> is a C string containing the attribute name.</p>
<p> In addition, a macro is provided that replaces 'Py<u>FindMethod'
<p> In addition, a macro is provided that replaces <code>Py_FindMethod</code>
calls with logic to perform the same sort of lookup that is
provided by 'Py</u>FindAttrString'.</p>
provided by <code>Py_FindAttrString</code>.</p>
<p> If an attribute name is contained in a Python string object,
rather than a C string object, then the macro <code>Py_FindAttr</code> should
be used to look up an attribute value.</p>
......@@ -317,10 +317,10 @@
</pre>
</p>
<p> This implementation will fail when an <code>ECSpam</code> object is
instantiated. The problem is that 'ECSpam._<u>init</u><u>' calls
'Spam.</u><u>init</u><u>', and 'Spam.</u><u>init</u><u>' can only be called with a
instantiated. The problem is that <code>ECSpam.__init__</code> calls
<code>Spam.__init__</code>, and <code>Spam.__init__</code> can only be called with a
Python instance (an object of type <code>"instance"</code>) as the first
argument. The first argument passed to 'Spam.</u><u>init</u>_' will be an
argument. The first argument passed to <code>Spam.__init__</code> will be an
<code>ECSpam</code> instance (an object of type <code>ECSPam</code>).</p>
<p> To overcome this problem, extension classes provide a class method
<code>inheritedAttribute</code> that can be used to obtain an inherited
......@@ -367,8 +367,8 @@
<p> Extension classes provide a similar mechanism for attributes that
are Python functions or inherited extension functions. In
addition, if an extension class attribute is an instance of an
extension class that defines an '_<u>of</u><u>' method, then when the
attribute is accessed through an instance, it's '</u><u>of</u>_' method
extension class that defines an <code>__of__</code> method, then when the
attribute is accessed through an instance, it's <code>__of__</code> method
will be called to create a bound method.</p>
<p> Consider the following example:
<pre>
......@@ -400,15 +400,15 @@
<h4> Computed Attributes</h4>
<p> It is not uncommon to wish to expose information via the
attribute interface without affecting implementation data
structures. One can use a custom '_<u>getattr</u><u><code> method to
structures. One can use a custom <code>__getattr__</code> method to
implement computed attributes, however, this can be a bit
cumbersome and can interfere with other uses of </code></u><u>getattr</u>_',
cumbersome and can interfere with other uses of <code>__getattr__</code>,
such as for persistence.</p>
<p> The '_<u>of</u><u>' protocol provides a convenient way to implement
<p> The <code>__of__</code> protocol provides a convenient way to implement
computed attributes. First, we define a ComputedAttribute
class. a ComputedAttribute is constructed with a function to
be used to compute an attribute, and calls the function when
it's '</u><u>of</u>_' method is called:<p> import ExtensionClass</p>
it's <code>__of__</code> method is called:<p> import ExtensionClass</p>
<h5> class ComputedAttribute(ExtensionClass.Base):</h5>
<p> def _<u>init</u>_(self, func): self.func=func</p>
<p> def _<u>of</u>_(self, parent): return self.func(parent)</p>
......@@ -429,15 +429,15 @@
function call. Extension classes introduce a new protocol that
provides extension classes greater control over how their
methods are called. If an extension class defines a special
method, '_<u>call</u>method_<u><code>, then this method will be called to
method, <code>__call_method__</code>, then this method will be called to
call the functions (or other callable object) wrapped by the
method. The method. </code></u><u>call</u>method__' should provide the same
method. The method. <code>__call_method__</code> should provide the same
interface as provided by the Python builtin <code>apply</code> function.</p>
<p> For example, consider the expression: <code>x.meth(arg1, arg2)</code>. The
expression is evaluated by first computing a method object that
wraps <code>x</code> and the attribute of <code>x</code> stored under the name <code>meth</code>.
Assuming that <code>x</code> has a '_<u>call</u>method_<u><code> method defined, then
the </code></u><u>call</u>method__' method of <code>x</code> will be called with two
Assuming that <code>x</code> has a <code>__call_method__</code> method defined, then
the <code>__call_method__</code> method of <code>x</code> will be called with two
arguments, the attribute of <code>x</code> stored under the name <code>meth</code>,
and a tuple containing <code>x</code>, <code>arg1</code>, and <code>arg2</code>.</p>
<p> To see how this feature may be used, see the Python module,
......@@ -470,21 +470,21 @@
</p>
<p> A bound method attribute is set by setting an attribute in it's
instance with a name consisting of the concatination of the
method's '_<u>name</u>_' attribute and the attribute name.
method's <code>__name__</code> attribute and the attribute name.
Attributes cannot be set on unbound methods.</p>
<h3> Class initialization</h3>
<p> Normal Python class initialization is similar to but subtley
different from instance initialization. An instance '_<u>init</u>_'
different from instance initialization. An instance <code>__init__</code>
function is called on an instance immediately <em>after</em> it is
created. An instance '_<u>init</u>_' function can use instance
created. An instance <code>__init__</code> function can use instance
information, like it's class and can pass the instance to other
functions. On the other hand, the code in class statements is
executed immediately <em>before</em> the class is created. This means
that the code in a class statement cannot use class attributes,
like '_<u>bases</u>_', or pass the class to functions.</p>
like <code>__bases__</code>, or pass the class to functions.</p>
<p> Extension classes provide a mechanism for specifying code to be
run <em>after</em> a class has been created. If a class or one of it's
base classes defines a '_<u>class</u>init__' method, then this method
base classes defines a <code>__class_init__</code> method, then this method
will be called just after a class has been created. The one
argument passed to the method will be the class, <em>not</em> an
instance of the class.</p>
......
......@@ -363,9 +363,9 @@
</p>
<p> This version includes <code>ExtensionClass.h</code>. The two declarations of
<code>MMtype</code> have been changed from <code>PyTypeObject</code> to <code>PyExtensionClass</code>.
The 'METHOD<u>CHAIN' macro has been used to add methods to the end of
The <code>METHOD_CHAIN</code> macro has been used to add methods to the end of
the definition for <code>MMtype</code>. The module function, newMMobject has
been replaced by the <code>MMtype</code> method, 'MM</u><u>init</u>_'. Note that this
been replaced by the <code>MMtype</code> method, <code>MM__init__</code>. Note that this
method does not create or return a new object. Finally, the lines:
<pre>
d = PyModule_GetDict(m);
......
......@@ -27,7 +27,7 @@
to implement "synchonized" classes and could be used to
implement argument type checking.</p></li>
<li><p>A protocol for class initialization that supports execution of a
special '_<u>class</u>init__' method after a class has been
special <code>__class_init__</code> method after a class has been
initialized. </p></li>
</ul>
......
......@@ -8,7 +8,7 @@
</th>
</tr>
<tr>
<td colspan=1 align=left valign=top><p> '_<u>str</u>_' </p>
<td colspan=1 align=left valign=top><p> <code>__str__</code> </p>
</td>
<td colspan=1 align=left valign=middle><p> This method converts the
the object to a string. </p>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment