[Zope3-checkins] CVS: zopeproducts/bugtracker/browser/StructuredText/regressions - Acquisition.ref:1.1 Acquisition.stx:1.1 ExtensionClass.ref:1.1 ExtensionClass.stx:1.1 InnerLinks.ref:1.1 InnerLinks.stx:1.1 Links.ref:1.1 Links.stx:1.1 MultiMapping.ref:1.1 MultiMapping.stx:1.1 create_referencesfiles.py:1.1 examples.ref:1.1 examples.stx:1.1 examples1.ref:1.1 examples1.stx:1.1 index.ref:1.1 index.stx:1.1 table.ref:1.1 table.stx:1.1

Stephan Richter srichter@cosmos.phy.tufts.edu
Thu, 24 Jul 2003 14:08:40 -0400


Update of /cvs-repository/zopeproducts/bugtracker/browser/StructuredText/regressions
In directory cvs.zope.org:/tmp/cvs-serv302/browser/StructuredText/regressions

Added Files:
	Acquisition.ref Acquisition.stx ExtensionClass.ref 
	ExtensionClass.stx InnerLinks.ref InnerLinks.stx Links.ref 
	Links.stx MultiMapping.ref MultiMapping.stx 
	create_referencesfiles.py examples.ref examples.stx 
	examples1.ref examples1.stx index.ref index.stx table.ref 
	table.stx 
Log Message:
First Checkin of the Bug Tracker. A list of features is the README.txt file
and a to-do list is in TODO.txt.

The code features the use of vocabularies and vocabulary fields.

There is still a bit of work to do, but I am pretty close to make it usable
for us.


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/Acquisition.ref ===
<html>
<head>
<title>Acquisition</title>
</head>
<body>
<h1>Acquisition</h1>
<p>  <a href="COPYRIGHT.html">Copyright (C) 1996-1998, Digital Creations</a>.</p>
<p>  Acquisition <a href="#ref1">[1]</a> is a mechanism that allows objects to obtain
  attributes from their environment.  It is similar to inheritence,
  except that, rather than traversing an inheritence hierarchy
  to obtain attributes, a containment hierarchy is traversed.</p>
<p>  The <a href="ExtensionClass.html">ExtensionClass</a>. release includes mix-in
  extension base classes that can be used to add acquisition as a
  feature to extension subclasses.  These mix-in classes use the
  context-wrapping feature of ExtensionClasses to implement
  acquisition. Consider the following example:
<pre>
    import ExtensionClass, Acquisition

    class C(ExtensionClass.Base):
      color='red'

    class A(Acquisition.Implicit):

      def report(self):
        print self.color

    a=A()
    c=C()
    c.a=A()

    c.a.report() # prints 'red'

    d=C()
    d.color='green'
    d.a=a

    d.a.report() # prints 'green'

    a.report() # raises an attribute error
</pre>
</p>
<p>  The class <code>A</code> inherits acquisition behavior from
  <code>Acquisition.Implicit</code>.  The object, <code>a</code>, "has" the color of
  objects <code>c</code> and <code>d</code> when it is accessed through them, but it
  has no color by itself.  The object <code>a</code> obtains attributes
  from it's environment, where it's environment is defined by
  the access path used to reach <code>a</code>.</p>
<h2>  Acquisition wrappers</h2>
<p>    When an object that supports acquisition is accessed through
    an extension class instance, a special object, called an
    acquisition wrapper, is returned.  In the example above, the
    expression <code>c.a</code> returns an acquisition wrapper that
    contains references to both <code>c</code> and <code>a</code>.  It is this wrapper
    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 <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'
</pre>
</p>
<p>    and:
<pre>
       'c.a.aq_self is a'
</pre>
</p>
<p>    both evaluate to true, but the expression:
<pre>
       'c.a is a'
</pre>
</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 <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
    ExtensionClass release, implicit and explicit aquisition.</p>
<h3>    Implicit acquisition</h3>
<p>      Implicit acquisition is so named because it searches for
      attributes from the environment automatically whenever an
      attribute cannot be obtained directly from an object or
      through inheritence.</p>
<p>      An attribute may be implicitly acquired if it's name does
      not begin with an underscore, <code>_</code>.</p>
<p>      To support implicit acquisition, an object should inherit
      from the mix-in class <code>Acquisition.Implicit</code>.</p>
<h3>    Explicit Acquisition</h3>
<p>      When explicit acquisition is used, attributes are not
      automatically obtained from the environment.  Instead, the
      method <code>aq_aquire</code> must be used, as in:
<pre>
        print c.a.aq_acquire('color')
</pre>
</p>
<p>      To support explicit acquisition, an object should inherit
      from the mix-in class <code>Acquisition.Explicit</code>.</p>
<h3>    Controlled Acquisition</h3>
<p>      A class (or instance) can provide attribute by attribute control
      over acquisition.  This is done by:</p>

<ul>
<li>subclassing from <code>Acquisition.Explicit</code>, and</li>
<li>setting all attributes that should be acquired to the special
        value: <code>Acquisition.Acquired</code>.  Setting an attribute to this
        value also allows inherited attributes to be overridden with
        acquired ones.<p>        For example, in:
<pre>
          class C(Acquisition.Explicit):
             id=1
             secret=2
             color=Acquisition.Acquired
             __roles__=Acquisition.Acquired
</pre>
</p>
<p>        The <em>only</em> attributes that are automatically acquired from
        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
        objects that smell like private objects.</p>
</li>

</ul>
<h3>    Filtered Acquisition</h3>
<p>      The acquisition method, <code>aq_acquire</code>, accepts two optional
      arguments. The first of the additional arguments is a
      "filtering" function that is used when considering whether to
      acquire an object.  The second of the additional arguments is an
      object that is passed as extra data when calling the filtering
      function and which defaults to <code>None</code>.</p>
<p>      The filter function is called with five arguments:</p>

<ul>
<li>The object that the <code>aq_acquire</code> method was called on,</li>
<li>The object where an object was found,</li>
<li>The name of the object, as passed to <code>aq_acquire</code>,</li>
<li>The object found, and</li>
<li>The extra data passed to <code>aq_acquire</code>.</li>

</ul>
<p>      If the filter returns a true object that the object found is
      returned, otherwise, the acquisition search continues.</p>
<p>      For example, in:
<pre>
        from Acquisition import Explicit

        class HandyForTesting:
            def __init__(self, name): self.name=name
            def __str__(self):
                return "%s(%s)" % (self.name, self.__class__.__name__)
            __repr__=__str__

        class E(Explicit, HandyForTesting): pass

        class Nice(HandyForTesting):
            isNice=1
            def __str__(self):
                return HandyForTesting.__str__(self)+' and I am nice!'
            __repr__=__str__

        a=E('a')
        a.b=E('b')
        a.b.c=E('c')
        a.p=Nice('spam')
        a.b.p=E('p')

        def find_nice(self, ancestor, name, object, extra):
            return hasattr(object,'isNice') and object.isNice

        print a.b.c.aq_acquire('p', find_nice)
</pre>
</p>
<p>      The filtered acquisition in the last line skips over the first
      attribute it finds with the name <code>p</code>, because the attribute
      doesn't satisfy the condition given in the filter. The output of
      the last line is:
<pre>
        spam(Nice) and I am nice!
</pre>
</p>
<h2>  Acquisition and methods</h2>
<p>    Python methods of objects that support acquisition can use
    acquired attributes as in the <code>report</code> method of the first example
    above.  When a Python method is called on an object that is
    wrapped by an acquisition wrapper, the wrapper is passed to the
    method as the first argument.  This rule also applies to
    user-defined method types and to C methods defined in pure mix-in
    classes.</p>
<p>    Unfortunately, C methods defined in extension base classes that
    define their own data structures, cannot use aquired attributes at
    this time.  This is because wrapper objects do not conform to the
    data structures expected by these methods.</p>
<h2>  Acquiring Acquiring objects</h2>
<p>    Consider the following example:
<pre>
      from Acquisition import Implicit

      class C(Implicit):
          def __init__(self, name): self.name=name
          def __str__(self):
              return "%s(%s)" % (self.name, self.__class__.__name__)
          __repr__=__str__

      a=C("a")
      a.b=C("b")
      a.b.pref="spam"
      a.b.c=C("c")
      a.b.c.color="red"
      a.b.c.pref="eggs"
      a.x=C("x")

      o=a.b.c.x
</pre>
</p>
<p>    The expression <code>o.color</code> might be expected to return <code>"red"</code>. In
    earlier versions of ExtensionClass, however, this expression
    failed.  Acquired acquiring objects did not acquire from the
    environment they were accessed in, because objects were only
    wrapped when they were first found, and were not rewrapped as they
    were passed down the acquisition tree.</p>
<p>    In the current release of ExtensionClass, the expression "o.color"
    does indeed return <code>"red"</code>.</p>
<p>    When searching for an attribute in <code>o</code>, objects are searched in
    the order <code>x</code>, <code>a</code>, <code>b</code>, <code>c</code>. So, for example, the expression,
    <code>o.pref</code> returns <code>"spam"</code>, not <code>"eggs"</code>.  In earlier releases of
    ExtensionClass, the attempt to get the <code>pref</code> attribute from <code>o</code>
    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 <code>__of__</code> method:</p>
<dl>
<dt>    <code>a.x</code></dt>
<dd><code>x.__of__(a)</code></dd>
<dt>    <code>a.b</code></dt>
<dd><code>b.__of__(a)</code></dd>
<dt>    <code>a.b.x</code></dt>
<dd><code>x.__of__(a).__of__(b.__of__(a))</code></dd>
<dt>    <code>a.b.c</code></dt>
<dd><code>c.__of__(b.__of__(a))</code></dd>
<dt>    <code>a.b.c.x</code></dt>
<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 <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
    times.</p>
<p><a name="ref1">[1]</a> Gil, J., Lorenz, D., 
   <a href="http://www.bell-labs.com/people/cope/oopsla/Oopsla96TechnicalProgramAbstracts.html#GilLorenz">Environmental Acquisition--A New Inheritance-Like Abstraction Mechanism</a>, 
   OOPSLA '96 Proceedings, ACM SIG-PLAN, October, 1996</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/Acquisition.stx ===
Acquisition

  "Copyright (C) 1996-1998, Digital Creations":COPYRIGHT.html.

  Acquisition [1] is a mechanism that allows objects to obtain
  attributes from their environment.  It is similar to inheritence,
  except that, rather than traversing an inheritence hierarchy
  to obtain attributes, a containment hierarchy is traversed.

  The "ExtensionClass":ExtensionClass.html. release includes mix-in
  extension base classes that can be used to add acquisition as a
  feature to extension subclasses.  These mix-in classes use the
  context-wrapping feature of ExtensionClasses to implement
  acquisition. Consider the following example::

    import ExtensionClass, Acquisition

    class C(ExtensionClass.Base):
      color='red'

    class A(Acquisition.Implicit):

      def report(self):
        print self.color

    a=A()
    c=C()
    c.a=A()

    c.a.report() # prints 'red'

    d=C()
    d.color='green'
    d.a=a

    d.a.report() # prints 'green'

    a.report() # raises an attribute error

  The class 'A' inherits acquisition behavior from
  'Acquisition.Implicit'.  The object, 'a', "has" the color of
  objects 'c' and 'd' when it is accessed through them, but it
  has no color by itself.  The object 'a' obtains attributes
  from it's environment, where it's environment is defined by
  the access path used to reach 'a'.

  Acquisition wrappers

    When an object that supports acquisition is accessed through
    an extension class instance, a special object, called an
    acquisition wrapper, is returned.  In the example above, the
    expression 'c.a' returns an acquisition wrapper that
    contains references to both 'c' and 'a'.  It is this wrapper
    that performs attribute lookup in 'c' when an attribute
    cannot be found in 'a'.

    Aquisition wrappers provide access to the wrapped objects
    through the attributes 'aq_parent', 'aq_self', 'aq_base'.  
    In the example above, the expressions::
      
       'c.a.aq_parent is c'

    and::

       'c.a.aq_self is a'

    both evaluate to true, but the expression::

       'c.a is a'

    evaluates to false, because the expression 'c.a' evaluates
    to an acquisition wrapper around 'c' and 'a', not 'a' itself.

    The attribute 'aq_base' is similar to 'aq_self'.  Wrappers may be
    nested and 'aq_self' may be a wrapped object.  The 'aq_base'
    attribute is the underlying object with all wrappers removed.

  Acquisition Control

    Two styles of acquisition are supported in the current
    ExtensionClass release, implicit and explicit aquisition.
  
    Implicit acquisition
    
      Implicit acquisition is so named because it searches for
      attributes from the environment automatically whenever an
      attribute cannot be obtained directly from an object or
      through inheritence.
  
      An attribute may be implicitly acquired if it's name does
      not begin with an underscore, '_'.
  
      To support implicit acquisition, an object should inherit
      from the mix-in class 'Acquisition.Implicit'.
  
    Explicit Acquisition
  
      When explicit acquisition is used, attributes are not
      automatically obtained from the environment.  Instead, the
      method 'aq_aquire' must be used, as in::
  
	print c.a.aq_acquire('color')
  
      To support explicit acquisition, an object should inherit
      from the mix-in class 'Acquisition.Explicit'.

    Controlled Acquisition

      A class (or instance) can provide attribute by attribute control
      over acquisition.  This is done by:

      - subclassing from 'Acquisition.Explicit', and

      - setting all attributes that should be acquired to the special
        value: 'Acquisition.Acquired'.  Setting an attribute to this
        value also allows inherited attributes to be overridden with
        acquired ones.

	For example, in::

	  class C(Acquisition.Explicit):
	     id=1
	     secret=2
	     color=Acquisition.Acquired
	     __roles__=Acquisition.Acquired

	The *only* attributes that are automatically acquired from
	containing objects are 'color', and '__roles__'.  Note also
	that the '__roles__' attribute is acquired even though it's
	name begins with an underscore.  In fact, the special
	'Acquisition.Acquired' value can be used in
	'Acquisition.Implicit' objects to implicitly acquire selected
	objects that smell like private objects.

    Filtered Acquisition

      The acquisition method, 'aq_acquire', accepts two optional
      arguments. The first of the additional arguments is a
      "filtering" function that is used when considering whether to
      acquire an object.  The second of the additional arguments is an
      object that is passed as extra data when calling the filtering
      function and which defaults to 'None'.

      The filter function is called with five arguments:

      - The object that the 'aq_acquire' method was called on,

      - The object where an object was found,

      - The name of the object, as passed to 'aq_acquire',

      - The object found, and

      - The extra data passed to 'aq_acquire'.

      If the filter returns a true object that the object found is
      returned, otherwise, the acquisition search continues.

      For example, in::

	from Acquisition import Explicit
	
	class HandyForTesting:
	    def __init__(self, name): self.name=name
	    def __str__(self):
		return "%s(%s)" % (self.name, self.__class__.__name__)
	    __repr__=__str__
	
	class E(Explicit, HandyForTesting): pass
	
	class Nice(HandyForTesting):
	    isNice=1
	    def __str__(self):
		return HandyForTesting.__str__(self)+' and I am nice!'
	    __repr__=__str__
	
	a=E('a')
	a.b=E('b')
	a.b.c=E('c')
	a.p=Nice('spam')
	a.b.p=E('p')
	
	def find_nice(self, ancestor, name, object, extra):
	    return hasattr(object,'isNice') and object.isNice
	
	print a.b.c.aq_acquire('p', find_nice)

      The filtered acquisition in the last line skips over the first
      attribute it finds with the name 'p', because the attribute
      doesn't satisfy the condition given in the filter. The output of
      the last line is::

        spam(Nice) and I am nice!

  Acquisition and methods

    Python methods of objects that support acquisition can use
    acquired attributes as in the 'report' method of the first example
    above.  When a Python method is called on an object that is
    wrapped by an acquisition wrapper, the wrapper is passed to the
    method as the first argument.  This rule also applies to
    user-defined method types and to C methods defined in pure mix-in
    classes.

    Unfortunately, C methods defined in extension base classes that
    define their own data structures, cannot use aquired attributes at
    this time.  This is because wrapper objects do not conform to the
    data structures expected by these methods.

  Acquiring Acquiring objects

    Consider the following example::

      from Acquisition import Implicit
      
      class C(Implicit):
	  def __init__(self, name): self.name=name
	  def __str__(self):
	      return "%s(%s)" % (self.name, self.__class__.__name__)
	  __repr__=__str__
      
      a=C("a")
      a.b=C("b")
      a.b.pref="spam"
      a.b.c=C("c")
      a.b.c.color="red"
      a.b.c.pref="eggs"
      a.x=C("x")

      o=a.b.c.x

    The expression 'o.color' might be expected to return '"red"'. In
    earlier versions of ExtensionClass, however, this expression
    failed.  Acquired acquiring objects did not acquire from the
    environment they were accessed in, because objects were only
    wrapped when they were first found, and were not rewrapped as they
    were passed down the acquisition tree.

    In the current release of ExtensionClass, the expression "o.color"
    does indeed return '"red"'.

    When searching for an attribute in 'o', objects are searched in
    the order 'x', 'a', 'b', 'c'. So, for example, the expression,
    'o.pref' returns '"spam"', not '"eggs"'.  In earlier releases of
    ExtensionClass, the attempt to get the 'pref' attribute from 'o'
    would have failed.

    If desired, the current rules for looking up attributes in complex
    expressions can best be understood through repeated application of
    the '__of__' method:

    'a.x' -- 'x.__of__(a)'

    'a.b' -- 'b.__of__(a)'

    'a.b.x' -- 'x.__of__(a).__of__(b.__of__(a))'

    'a.b.c' -- 'c.__of__(b.__of__(a))'

    'a.b.c.x' --
        'x.__of__(a).__of__(b.__of__(a)).__of__(c.__of__(b.__of__(a)))'

    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 '__of__' method, lookup proceeds from left to right.

    Note that heuristics are used to avoid most of the repeated
    lookups. For example, in the expression: 'a.b.c.x.foo', the object
    'a' is searched no more than once, even though it is wrapped three
    times.

.. [1] Gil, J., Lorenz, D., 
   "Environmental Acquisition--A New Inheritance-Like Abstraction Mechanism",
   http://www.bell-labs.com/people/cope/oopsla/Oopsla96TechnicalProgramAbstracts.html#GilLorenz, 
   OOPSLA '96 Proceedings, ACM SIG-PLAN, October, 1996
	 


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/ExtensionClass.ref ===
<html>
<head>
<title>Extension Classes, Python Extension Types Become Classes</title>
</head>
<body>
<h1>Extension Classes, Python Extension Types Become Classes</h1>
<p>  Jim Fulton, Digital Creations, Inc.
  jim@digicool.com</p>
<p>  <a href="COPYRIGHT.html">Copyright (C) 1996-1998, Digital Creations</a>.</p>
<h2>  Abstract</h2>
<p>    A lightweight mechanism has been developed for making Python
    extension types more class-like.  Classes can be developed in an
    extension language, such as C or C++, and these classes can be
    treated like other python classes:</p>

<ul>
<li>They can be sub-classed in python,</li>
<li>They provide access to method documentation strings, and</li>
<li>They can be used to directly create new instances.</li>

</ul>
<p>    An example class shows how extension classes are implemented and how
    they differ from extension types.</p>
<p>    Extension classes provide additional extensions to class and
    instance semantics, including:</p>

<ul>
<li>A protocol for accessing subobjects "in the context of" their
      containers.  This is used to implement custom method types
      and <a href="Acquisition.html">environmental acquisition</a>.</li>
<li>A protocol for overriding method call semantics.  This is used
      to implement "synchonized" classes and could be used to
      implement argument type checking.</li>
<li>A protocol for class initialization that supports execution of a
      special <code>__class_init__</code> method after a class has been
      initialized. </li>

</ul>
<p>    Extension classes illustrate how the Python class mechanism can be
    extended and may provide a basis for improved or specialized class
    models. </p>
<h2>  Releases</h2>
<p>    To find out what's changed in this release,
    see the <a href="release.html">release notes</a>.</p>
<h2>  Problem</h2>
<p>    Currently, Python provides two ways of defining new kinds of objects:</p>

<ul>
<li>Python classes</li>
<li>Extension types</li>

</ul>
<p>    Each approach has it's strengths.  Extension types provide much greater
    control to the programmer and, generally, better performance.  Because
    extension types are written in C, the programmer has greater access to 
    external resources. (Note that Python's use of the term type has
    little to do with the notion of type as a formal specification.)</p>
<p>    Classes provide a higher level of abstraction and are generally much
    easier to develop.  Classes provide full inheritance support, while
    support for inheritance when developing extension types is very
    limited. Classes provide run-time meta-data, such as method documentation
    strings, that are useful for documentation and discovery.  Classes
    act as factories for creating instances, while separate functions
    must be provided to create instances of types.</p>
<p>    It would be useful to combine the features of the two approaches.  It 
    would be useful to be able to have better support for inheritance for
    types, or to be able to subclass from types in Python.  It would be
    useful to be able to have class-like meta-data support for types and
    the ability to construct instances directly from types.</p>
<p>    Our software is developed in Python.  When necessary, we convert
    debugged Python routines and classes to C for improved
    performance.  In most cases, a small number of methods in a class
    is responsible for most of the computation.  It should be possible
    to convert only these methods to C, while leaving the other method
    in Python.  A natural way to approach this is to create a base
    class in C that contains only the performance-critical aspects of
    a class' implementation and mix this base class into a Python
    class. </p>
<p>    We have need, in a number of projects, for semantics that are
    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="#ref1">[1]</a> that
    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, <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
    instance attribute, the attribute value is bound together with the
    instance in a method object <em>if and only if</em> the attribute value is a
    python function.  For some applications, we might also want to be
    able to bind extension functions, or other types of callable
    objects, such as HTML document templates <a href="#ref2">[2]</a>. Furthermore,
    we might want to have greater control over how objects are bound.
    For example, we might want to bind instances and callable objects
    with special method objects that assure that no more than one thread
    accesses the object or method at one time.</p>
<p>    We can provide these special semantics in extension types, but we
    wish to provide them for classes developed in Python.</p>
<h2>  Background</h2>
<p>    At the first Python Workshop, Don Beaudry presented work <a href="#ref3">[3]</a> done
    at V.I. Corp to integrate Python with C++ frameworks.  This system
    provided a number of important features, including:</p>

<ul>
<li>Definition of extension types that provide class-like meta-data
      and that can be called to create instances.</li>
<li>Ability to subclass in python from C types.</li>
<li>Ability to define classes in python who's data are stored as
      C structures rather than in dictionaries to better interface to
      C and C++ libraries, and for better performance.</li>
<li>Less dynamic data structures.  In particular, the data structure
      for a class is declared during class definition.</li>
<li>Support for enumeration types.</li>

</ul>
<p>    This work was not released, initially.</p>
<p>    Shortly after the workshop, changes were made to Python to support
    the sub-classing features described in <a href="#ref3">[3]</a>.  These changes were not
    documented until the fourth Python Workshop <a href="#ref4">[4]</a>.</p>
<p>    At the third Python workshop, I presented some work I had done on
    generating module documentation for extension types.  Based on the
    discussion at this workshop, I developed a meta-type proposal <a href="#ref5">[5]</a>.
    This meta-type proposal was for an object that simply stored
    meta-information for a type, for the purpose of generating module
    documentation.</p>
<p>    In the summer of 1996, Don Beaudry released the system described in
    <a href="#ref3">[3]</a> under the name MESS <a href="#ref6">[6]</a>. MESS addresses a number of needs but
    has a few drawbacks:</p>

<ul>
<li>Only single inheritance is supported.</li>
<li>The mechanisms for defining MESS extension types is very different
      from and more complicated than the standard Python type creation
      mechanism.</li>
<li>Defining MESS types requires the use of an extensive C
      applications programming interface.  This presents problems for
      configuring dynamically-loaded extension modules unless the MESS
      library is linked into the Python interpreter.</li>
<li>Because the system tries to do a number of different things, it is
      fairly large, about 15,000 lines.</li>
<li>There is very little documentation, especially for the C
      programming interface.</li>
<li>The system is a work in progress, with a number of outstanding
      bugs.</li>

</ul>
<p>    As MESS matures, we expect most of these problems to be addressed.</p>
<h2>  Extension Classes</h2>
<p>    To meet short term needs for a C-based persistence mechanism <a href="#ref1">[1]</a>, an
    extension class module was developed using the mechanism described
    in <a href="#ref4">[4]</a> and building on ideas from MESS <a href="#ref6">[6]</a>.  The extension class module
    recasts extension types as "extension classes" by seeking to
    eliminate, or at least reduce semantic differences between types and
    classes. The module was designed to meet the following goal:</p>

<ul>
<li>Provide class-like behavior for extension types, including
      interfaces for meta information and for constructing instances.</li>
<li>Support sub-classing in Python from extension classes, with support
      for multiple inheritance.</li>
<li>Provide a small hardened implementation that can be used for
      current products.</li>
<li>Provide a mechanism that requires minimal modification to existing
      extension types.</li>
<li>Provide a basis for research on alternative semantics for classes
      and inheritance.</li>

</ul>
<p>    <strong>Note:</strong> I use <em>non-standard</em> terminology here.  By standard
    <em>python</em> terminology, only standard python classes can be called
    classes.  ExtensionClass "classes" are technically just "types"
    that happen to swim, walk and quack like python classes.</p>
<h3>    Base extension classes and extension subclasses</h3>
<p>      Base extension classes are implemented in C.  Extension subclasses
      are implemented in Python and inherit, directly or indirectly from
      one or more base extension classes.  An extension subclass may
      inherit from base extension classes, extension subclasses, and
      ordinary python classes.  The usual inheritance order rules
      apply.  Currently, extension subclasses must conform to the
      following two rules:</p>

<ul>
<li>The first super class listed in the class statement defining an
        extension subclass must be either a base extension class or an
        extension subclass.  This restriction will be removed in
        Python-1.5.</li>
<li>At most one base extension direct or indirect super class may
        define C data members.  If an extension subclass inherits from
        multiple base extension classes, then all but one must be mix-in
        classes that provide extension methods but no data.</li>

</ul>
<h3>    Meta Information</h3>
<p>      Like standard python classes, extension classes have the following
      attributes containing meta-data:</p>
<dl>
<dt>      <code>__doc__</code></dt>
<dd>a documentation string for the class,</dd>
<dt>      <code>__name__</code></dt>
<dd>the class name,</dd>
<dt>      <code>__bases__</code></dt>
<dd>a sequence of base classes,</dd>
<dt>      <code>__dict__</code></dt>
<dd>a class dictionary, and</dd>
<dt>      <code>__module__</code></dt>
<dd>the name of the module in which the class was
                      defined. </dd>
</dl>
<p>      The class dictionary provides access to unbound methods and their
      documentation strings, including extension methods and special
      methods, such as methods that implement sequence and numeric
      protocols.  Unbound methods can be called with instance first
      arguments.</p>
<h3>    Subclass instance data</h3>
<p>      Extension subclass instances have instance dictionaries, just
      like Python class instances do.  When fetching attribute values,
      extension class instances will first try to obtain data from the
      base extension class data structure, then from the instance
      dictionary, then from the class dictionary, and finally from base
      classes.  When setting attributes, extension classes first attempt
      to use extension base class attribute setting operations, and if
      these fail, then data are placed in the instance dictionary.</p>
<h2>  Implementing base extension classes</h2>
<p>    A base extension class is implemented in much the same way that an
    extension type is implemented, except:</p>

<ul>
<li>The include file, <code>ExtensionClass.h</code>, must be included.</li>
<li>The type structure is declared to be of type <code>PyExtensionClass</code>, rather 
      than of type <code>PyTypeObject</code>.</li>
<li>The type structure has an additional member that must be defined
      after the documentation string.  This extra member is a method chain
      (<code>PyMethodChain</code>) containing a linked list of method definition
      (<code>PyMethodDef</code>) lists.  Method chains can be used to implement
      method inheritance in C.  Most extensions don't use method chains,
      but simply define method lists, which are null-terminated arrays
      of method definitions.  A macro, <code>METHOD_CHAIN</code> is defined in
      <code>ExtensionClass.h</code> that converts a method list to a method chain.
      (See the example below.)</li>
<li>Module functions that create new instances must be replaced by 
      <code>__init__</code> methods that initialize, but does not create storage for 
      instances.</li>
<li>The extension class must be initialized and exported to the module
      with:
<pre>
          PyExtensionClass_Export(d,"name",type);
</pre>
</li>

</ul>
<p>      where <code>name</code> is the module name and <code>type</code> is the extension class
      type object.<h2>    Attribute lookup</h2>
<p>      Attribute lookup is performed by calling the base extension class
      <code>getattr</code> operation for the base extension class that includes C
      data, or for the first base extension class, if none of the base
      extension classes include C data.  <code>ExtensionClass.h</code> defines a
      macro <code>Py_FindAttrString</code> that can be used to find an object's
      attributes that are stored in the object's instance dictionary or
      in the object's class or base classes:
<pre>
         v = Py_FindAttrString(self,name);
</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 <code>Py_FindMethod</code>
      calls with logic to perform the same sort of lookup that is
      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>
<h2>    Linking</h2>
<p>      The extension class mechanism was designed to be useful with
      dynamically linked extension modules.  Modules that implement
      extension classes do not have to be linked against an extension
      class library.  The macro <code>PyExtensionClass_Export</code> imports the
      <code>ExtensionClass</code> module and uses objects imported from this module
      to initialize an extension class with necessary behavior.</p>
<h2>    Example: MultiMapping objects</h2>
<p>      An <a href="MultiMapping.html">example</a>, is provided that illustrates the
      changes needed to convert an existing type to an ExtensionClass.</p>
</p>
<h2>  Implementing base extension class constructors</h2>
<p>    Some care should be taken when implementing or overriding base
    class constructors.  When a Python class overrides a base class
    constructor and fails to call the base class constructor, a
    program using the class may fail, but it will not crash the
    interpreter. On the other hand, an extension subclass that
    overrides a constructor in an extension base class must call the
    extension base class constructor or risk crashing the interpreter.
    This is because the base class constructor may set C pointers that,
    if not set properly, will cause the interpreter to crash when
    accessed.  This is the case with the <code>MultiMapping</code> extension base
    class shown in the example above.</p>
<p>    If no base class constructor is provided, extension class instance
    memory will be initialized to 0.  It is a good idea to design
    extension base classes so that instance methods check for
    uninitialized memory and perform initialialization if necessary.
    This was not done above to simplify the example.</p>
<h2>  Overriding methods inherited from Python base classes</h2>
<p>    A problem occurs when trying to overide methods inherited from
    Python base classes.  Consider the following example:
<pre>
      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
          self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
          Spam.__init__(self,name)
          self.favorite_color=favorite_color
</pre>
</p>
<p>    This implementation will fail when an <code>ECSpam</code> object is
    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 <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
    attribute that is suitable for calling with an extension class
    instance.  Using the <code>inheritedAttribute</code> method, the above
    example can be rewritten as:
<pre>
      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
          self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
          ECSpam.inheritedAttribute('__init__')(self,name)
          self.favorite_color=favorite_color
</pre>
</p>
<p>    This isn't as pretty but does provide the desired result.</p>
<h2>  New class and instance semantics</h2>
<h3>    Context Wrapping</h3>
<p>      It is sometimes useful to be able to wrap up an object together
      with a containing object.  I call this "context wrapping"
      because an object is accessed in the context of the object it is
      accessed through.</p>
<h4>      We have found many applications for this, including:</h4>

<ul>
<li>User-defined method objects, </li>
<li><a href="Acquisition.html">Acquisition</a>, and</li>
<li>Computed attributes</li>

</ul>
<h4>      User-defined method objects</h4>
<p>        Python classes wrap Python function attributes into methods.  When a
        class has a function attribute that is accessed as an instance
        attribute, a method object is created and returned that contains
        references to the original function and instance.  When the method
        is called, the original function is called with the instance as the
        first argument followed by any arguments passed to the method.</p>
<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 <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>
          import ExtensionClass

          class CustomMethod(ExtensionClass.Base):

            def __call__(self,ob): 
              print 'a %s was called' % ob.__class__.__name__

            class wrapper:

              def __init__(self,m,o): self.meth, self.ob=m,o

              def __call__(self): self.meth(self.ob)

            def __of__(self,o): return self.wrapper(self,o)

          class bar(ExtensionClass.Base):
            hi=CustomMethod()

          x=bar()
          hi=x.hi()
</pre>
</p>
<p>        Note that <code>ExtensionClass.Base</code> is a base extension class that
        provides very basic ExtensionClass behavior. </p>
<p>        When run, this program outputs: <code>a bar was called</code>.</p>
<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 <code>__getattr__</code> method to
        implement computed attributes, however, this can be a bit
        cumbersome and can interfere with other uses of <code>__getattr__</code>,
        such as for persistence.</p>
<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 <code>__of__</code> method is called:<p>          import ExtensionClass</p>
<h5>          class ComputedAttribute(ExtensionClass.Base):</h5>
<p>            def __init__(self, func): self.func=func</p>
<p>            def __of__(self, parent): return self.func(parent)</p>
</p>
<p>        Then we can use this class to create computed attributes.  In the
        example below, we create a computed attribute, 'radius':<p>          from math import sqrt</p>
<h5>          class Point(ExtensionClass.Base):</h5>
<p>            def __init__(self, x, y): self.x, self.y = x, y</p>
<p>            radius=ComputedAttribute(lambda self: sqrt(self.x<strong>2+self.y</strong>2))</p>
</p>
<h5>        which we can use just like an ordinary attribute:</h5>
<p>          p=Point(2,2)
          print p.radius</p>
<h3>    Overriding method calls</h3>
<p>      Normally, when a method is called, the function wrapped by the
      method is called directly by the method.  In some cases, it is
      useful for user-defined logic to participate in the actual
      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, <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>__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 <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,
      <code>Syn.py</code>, which is included in the ExtensionClass distribution.
      This module provides a mix-in class that provides Java-like
      "synchonized" classes that limit access to their methods to one
      thread at a time.</p>
<p>      An interesting application of this mechanism would be to
      implement interface checking on method calls.</p>
<h3>    Method attributes</h3>
<p>      Methods of ExtensionClass instances can have user-defined
      attributes, which are stored in their associated instances.</p>
<p>      For example:
<pre>
        class C(ExtensionClass.Base):

          def get_secret(self):
            "Get a secret"
            ....

        c=C()

        c.f.__roles__=['Trusted People']

        print c.f.__roles__ # outputs ['Trusted People']
        print c.f__roles__  # outputs ['Trusted People']

        print C.f.__roles__ # fails, unbound method
</pre>
</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 <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 <code>__init__</code>
      function is called on an instance immediately <em>after</em> it is
      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 <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 <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>
<h2>  Useful macros defined in ExtensionClass.h</h2>
<p>    A number of useful macros are defined in ExtensionClass.h.
    These are documented in <code>ExtensionClass.h</code>.</p>
<h2>  Pickleability</h2>
<p>    Classes created with ExtensionClass, including extension base
    classes are automatically pickleable.  The usual gymnastics
    necessary to pickle <code>non-standard</code> types are not necessray for
    types that have been modified to be extension base classes.</p>
<h2>  Status</h2>
<p>    The current release of the extension class module is <a href="http://www.digicool.com/releases/ExtensionClass/ExtensionClass-1.1.tar.gz">1.1</a>.
    The core implementation has less than four thousand lines of code,
    including comments.  This release requires Python 1.4 or higher.</p>
<p>    To find out what's changed in this release, see the
    <a href="release.html">release notes</a>.</p>
<p>    <a href="Installation.html">Installation instructions</a>, are provided.</p>
<h2>  Issues</h2>
<p>    There are a number of issues that came up in the course of this work
    and that deserve mention.</p>

<ul>
<li>In Python 1.4, the class extension mechanism described in <a href="#ref4">[4]</a> required
      that the first superclass in a list of super-classes must be of the
      extended class type.  This may not be convenient if mix-in
      behavior is desired.  If a list of base classes starts with a
      standard python class, but includes an extension class, then an
      error was raised.  It would be more useful if, when a list of base
      classes contains one or more objects that are not python classes,
      the first such object was used to control the extended class
      definition.  To get around this, the <code>ExtensionClass</code> module exports
      a base extension class, <code>Base</code>, that can be used as the first base
      class in a list of base classes to assure that an extension
      subclass is created.<p>      Python 1.5 allows the class extension even if the first non-class
      object in the list of base classes is not the first object in
      the list.  This issue appears to go away in Python 1.5, however,
      the restriction that the first non-class object in a list of
      base classes must be the first in the list may reappear in later
      versions of Python.</p>
</li>
<li>Currently, only one base extension class can define any data in
      C.  The data layout of subclasses-instances is the same as for the
      base class that defines data in C, except that the data structure
      is extended to hold an instance dictionary.  The data structure
      begins with a standard python header, and extension methods expect
      the C instance data to occur immediately after the object header.  If
      two or more base classes defined C data, the methods for the
      different base classes would expect their data to be in the same
      location. A solution might be to allocate base class instances and
      store pointers to these instances in the subclass data structure.
      The method binding mechanism would have to be a more complicated
      to make sure that methods were bound to the correct base data
      structure.  Alternatively, the signature of C methods could be
      expanded to allow pointers to expected class data to be passed
      in addition to object pointers.</li>
<li>There is currently no support for sub-classing in C, beyond that
      provided by method chains.</li>
<li>Rules for mixed-type arithmetic are different for python class
      instances than they are for extension type instances.  Python
      classes can define right and left versions of numeric binary
      operators, or they can define a coercion operator for converting
      binary operator operands to a common type.  For extension types,
      only the latter, coercion-based, approach is supported.  The
      coercion-based approach does not work well for many data types for
      which coercion rules depend on the operator.  Because extension
      classes are based on extension types, they are currently limited
      to the coercion-based approach.  It should be possible to
      extend the extension class implementation to allow both types of
      mixed-type arithmetic control.</li>
<li>I considered making extension classes immutable, meaning that
      class attributes could not be set after class creation.  I also
      considered making extension subclasses cache inherited
      attributes.  Both of these are related and attractive for some
      applications, however, I decided that it would be better to retain
      standard class instance semantics and provide these features as
      options at a later time.</li>
<li>The extension class module defines new method types to bind C and
      python methods to extension class instances.  It would be useful
      for these method objects to provide access to function call
      information, such as the number and names of arguments and the
      number of defaults, by parsing extension function documentation
      strings.</li>

</ul>
<h2>  Applications</h2>
<p>    Aside from test and demonstration applications, the extension class
    mechanism has been used to provide an extension-based implementation
    of the persistence mechanism described in <a href="#ref1">[1]</a>.  We have developed
    this further to provide features such as automatic deactivation of
    objects not used after some period of time and to provide more
    efficient persistent-object cache management.</p>
<p>    Acquisition has been heavily used in our recent products.
    Synchonized classes have also been used in recent products.</p>
<h2>  Summary</h2>
<p>    The extension-class mechanism described here provides a way to add
    class services to extension types.  It allows:
<ul>
<li>Sub-classing extension classes in Python,</li>
<li>Construction of extension class instances by calling extension
        classes,</li>
<li>Extension classes to provide meta-data, such as unbound methods
        and their documentation string.</li>

</ul>
</p>
<p>    In addition, the extension class module provides a relatively
    concise example of the use of mechanisms that were added to Python
    to support MESS <a href="#ref6">[6]</a>, and that were described at the fourth Python
    Workshop <a href="#ref4">[4]</a>.  It is hoped that this will spur research in improved
    and specialized models for class implementation in Python.</p>
<p>  References</p>
<p><a name="ref1">[1]</a> Fulton, J., <a href="http://www.digicool.com/papers/Persistence.html">Providing Persistence for World-Wide-Web Applications</a>,
 Proceedings of the 5th Python Workshop.</p>
<p><a name="ref2">[2]</a> Page, R. and Cropper, S., <a href="http://www.digicool.com/papers/DocumentTemplate.html">Document Template</a>,
 Proceedings of the 5th Python Workshop.</p>
<p><a name="ref3">[3]</a> Beaudry, D., <a href="http://www.python.org/workshops/1994-11/BuiltInClasses/BuiltInClasses_1.html">Deriving Built-In Classes in Python</a>,
 Proceedings of the First International Python Workshop.</p>
<p><a name="ref4">[4]</a> Van Rossum, G., <a href="http://www.python.org/workshops/1996-06/notes/thursday.html">Don Beaudry Hack - MESS</a>,
 presented in the Developer's Future Enhancements session of the 
 4th Python Workshop. </p>
<p><a name="ref5">[5]</a> Fulton, J., <a href="http://www.digicool.com/jim/MetaType.c">Meta-Type Object</a>,
 This is a small proposal, the text of which is contained in a 
 sample implementation source file,  </p>
<p><a name="ref6">[6]</a> Beaudry, D., and Ascher, D., <a href="http://starship.skyport.net/~da/mess/">The Meta-Extension Set</a>.</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/ExtensionClass.stx ===
Extension Classes, Python Extension Types Become Classes

  Jim Fulton, Digital Creations, Inc.
  jim@digicool.com

  "Copyright (C) 1996-1998, Digital Creations":COPYRIGHT.html.

  Abstract
  
    A lightweight mechanism has been developed for making Python
    extension types more class-like.  Classes can be developed in an
    extension language, such as C or C++, and these classes can be
    treated like other python classes:
  
    - They can be sub-classed in python,
  
    - They provide access to method documentation strings, and
  
    - They can be used to directly create new instances.
  
    An example class shows how extension classes are implemented and how
    they differ from extension types.
  
    Extension classes provide additional extensions to class and
    instance semantics, including:

    - A protocol for accessing subobjects "in the context of" their
      containers.  This is used to implement custom method types
      and "environmental acquisition":Acquisition.html.

    - A protocol for overriding method call semantics.  This is used
      to implement "synchonized" classes and could be used to
      implement argument type checking.

    - A protocol for class initialization that supports execution of a
      special '__class_init__' method after a class has been
      initialized. 
  
    Extension classes illustrate how the Python class mechanism can be
    extended and may provide a basis for improved or specialized class
    models. 

  Releases

    To find out what's changed in this release,
    see the "release notes":release.html.
  
  Problem
  
    Currently, Python provides two ways of defining new kinds of objects:
  
    - Python classes
  
    - Extension types
  
    Each approach has it's strengths.  Extension types provide much greater
    control to the programmer and, generally, better performance.  Because
    extension types are written in C, the programmer has greater access to 
    external resources. (Note that Python's use of the term type has
    little to do with the notion of type as a formal specification.)
  
    Classes provide a higher level of abstraction and are generally much
    easier to develop.  Classes provide full inheritance support, while
    support for inheritance when developing extension types is very
    limited. Classes provide run-time meta-data, such as method documentation
    strings, that are useful for documentation and discovery.  Classes
    act as factories for creating instances, while separate functions
    must be provided to create instances of types.
  
    It would be useful to combine the features of the two approaches.  It 
    would be useful to be able to have better support for inheritance for
    types, or to be able to subclass from types in Python.  It would be
    useful to be able to have class-like meta-data support for types and
    the ability to construct instances directly from types.

    Our software is developed in Python.  When necessary, we convert
    debugged Python routines and classes to C for improved
    performance.  In most cases, a small number of methods in a class
    is responsible for most of the computation.  It should be possible
    to convert only these methods to C, while leaving the other method
    in Python.  A natural way to approach this is to create a base
    class in C that contains only the performance-critical aspects of
    a class' implementation and mix this base class into a Python
    class. 

    We have need, in a number of projects, for semantics that are
    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 [1] that
    redefines '__getattr__' and '__setattr__' to take storage-related
    actions when object state is accessed or modified.  We want to be
    able to take certain actions on *every* attribute reference, but
    for python class instances, '__getattr__' is only called when
    attribute lookup fails by normal means.

    As another example, we would like to have greater control over how
    methods are bound.  Currently, when accessing a class
    instance attribute, the attribute value is bound together with the
    instance in a method object *if and only if* the attribute value is a
    python function.  For some applications, we might also want to be
    able to bind extension functions, or other types of callable
    objects, such as HTML document templates [2]. Furthermore,
    we might want to have greater control over how objects are bound.
    For example, we might want to bind instances and callable objects
    with special method objects that assure that no more than one thread
    accesses the object or method at one time.
  
    We can provide these special semantics in extension types, but we
    wish to provide them for classes developed in Python.
  
  Background
  
    At the first Python Workshop, Don Beaudry presented work [3] done
    at V.I. Corp to integrate Python with C++ frameworks.  This system
    provided a number of important features, including:
  
    - Definition of extension types that provide class-like meta-data
      and that can be called to create instances.
  
    - Ability to subclass in python from C types.
  
    - Ability to define classes in python who's data are stored as
      C structures rather than in dictionaries to better interface to
      C and C++ libraries, and for better performance.
  
    - Less dynamic data structures.  In particular, the data structure
      for a class is declared during class definition.
  
    - Support for enumeration types.
  
    This work was not released, initially.
  
    Shortly after the workshop, changes were made to Python to support
    the sub-classing features described in [3].  These changes were not
    documented until the fourth Python Workshop [4].
  
    At the third Python workshop, I presented some work I had done on
    generating module documentation for extension types.  Based on the
    discussion at this workshop, I developed a meta-type proposal [5].
    This meta-type proposal was for an object that simply stored
    meta-information for a type, for the purpose of generating module
    documentation.
  
    In the summer of 1996, Don Beaudry released the system described in
    [3] under the name MESS [6]. MESS addresses a number of needs but
    has a few drawbacks:
  
    - Only single inheritance is supported.
  
    - The mechanisms for defining MESS extension types is very different
      from and more complicated than the standard Python type creation
      mechanism.
  
    - Defining MESS types requires the use of an extensive C
      applications programming interface.  This presents problems for
      configuring dynamically-loaded extension modules unless the MESS
      library is linked into the Python interpreter.
  
    - Because the system tries to do a number of different things, it is
      fairly large, about 15,000 lines.
  
    - There is very little documentation, especially for the C
      programming interface.
  
    - The system is a work in progress, with a number of outstanding
      bugs.
  
    As MESS matures, we expect most of these problems to be addressed.
  
  Extension Classes
  
    To meet short term needs for a C-based persistence mechanism [1], an
    extension class module was developed using the mechanism described
    in [4] and building on ideas from MESS [6].  The extension class module
    recasts extension types as "extension classes" by seeking to
    eliminate, or at least reduce semantic differences between types and
    classes. The module was designed to meet the following goal:
  
    - Provide class-like behavior for extension types, including
      interfaces for meta information and for constructing instances.
  
    - Support sub-classing in Python from extension classes, with support
      for multiple inheritance.
  
    - Provide a small hardened implementation that can be used for
      current products.
  
    - Provide a mechanism that requires minimal modification to existing
      extension types.
  
    - Provide a basis for research on alternative semantics for classes
      and inheritance.

    **Note:** I use *non-standard* terminology here.  By standard
    *python* terminology, only standard python classes can be called
    classes.  ExtensionClass "classes" are technically just "types"
    that happen to swim, walk and quack like python classes.
   
    Base extension classes and extension subclasses
  
      Base extension classes are implemented in C.  Extension subclasses
      are implemented in Python and inherit, directly or indirectly from
      one or more base extension classes.  An extension subclass may
      inherit from base extension classes, extension subclasses, and
      ordinary python classes.  The usual inheritance order rules
      apply.  Currently, extension subclasses must conform to the
      following two rules:
  
      - The first super class listed in the class statement defining an
	extension subclass must be either a base extension class or an
	extension subclass.  This restriction will be removed in
	Python-1.5.
  
      - At most one base extension direct or indirect super class may
	define C data members.  If an extension subclass inherits from
	multiple base extension classes, then all but one must be mix-in
	classes that provide extension methods but no data.
  
    Meta Information
  
      Like standard python classes, extension classes have the following
      attributes containing meta-data:
  
      '__doc__'   -- a documentation string for the class,
  		 
      '__name__'  -- the class name,
  		 
      '__bases__' -- a sequence of base classes,
  		 
      '__dict__'  -- a class dictionary, and

      '__module__' -- the name of the module in which the class was
                      defined. 
  
      The class dictionary provides access to unbound methods and their
      documentation strings, including extension methods and special
      methods, such as methods that implement sequence and numeric
      protocols.  Unbound methods can be called with instance first
      arguments.
  
    Subclass instance data
  
      Extension subclass instances have instance dictionaries, just
      like Python class instances do.  When fetching attribute values,
      extension class instances will first try to obtain data from the
      base extension class data structure, then from the instance
      dictionary, then from the class dictionary, and finally from base
      classes.  When setting attributes, extension classes first attempt
      to use extension base class attribute setting operations, and if
      these fail, then data are placed in the instance dictionary.
  
  Implementing base extension classes
  
    A base extension class is implemented in much the same way that an
    extension type is implemented, except:
  
    - The include file, 'ExtensionClass.h', must be included.
  
    - The type structure is declared to be of type 'PyExtensionClass', rather 
      than of type 'PyTypeObject'.
  
    - The type structure has an additional member that must be defined
      after the documentation string.  This extra member is a method chain
      ('PyMethodChain') containing a linked list of method definition
      ('PyMethodDef') lists.  Method chains can be used to implement
      method inheritance in C.  Most extensions don't use method chains,
      but simply define method lists, which are null-terminated arrays
      of method definitions.  A macro, 'METHOD_CHAIN' is defined in
      'ExtensionClass.h' that converts a method list to a method chain.
      (See the example below.)
  
    - Module functions that create new instances must be replaced by 
      '__init__' methods that initialize, but does not create storage for 
      instances.
  
    - The extension class must be initialized and exported to the module
      with::
  
	  PyExtensionClass_Export(d,"name",type);
  
      where 'name' is the module name and 'type' is the extension class
      type object.
  
    Attribute lookup
  
      Attribute lookup is performed by calling the base extension class
      'getattr' operation for the base extension class that includes C
      data, or for the first base extension class, if none of the base
      extension classes include C data.  'ExtensionClass.h' defines a
      macro 'Py_FindAttrString' that can be used to find an object's
      attributes that are stored in the object's instance dictionary or
      in the object's class or base classes::
  
	 v = Py_FindAttrString(self,name);
  
      where 'name' is a C string containing the attribute name.

      In addition, a macro is provided that replaces 'Py_FindMethod'
      calls with logic to perform the same sort of lookup that is
      provided by 'Py_FindAttrString'.

      If an attribute name is contained in a Python string object,
      rather than a C string object, then the macro 'Py_FindAttr' should
      be used to look up an attribute value.
  
    Linking
  
      The extension class mechanism was designed to be useful with
      dynamically linked extension modules.  Modules that implement
      extension classes do not have to be linked against an extension
      class library.  The macro 'PyExtensionClass_Export' imports the
      'ExtensionClass' module and uses objects imported from this module
      to initialize an extension class with necessary behavior.
  
    Example: MultiMapping objects

      An "example":MultiMapping.html, is provided that illustrates the
      changes needed to convert an existing type to an ExtensionClass.

  Implementing base extension class constructors

    Some care should be taken when implementing or overriding base
    class constructors.  When a Python class overrides a base class
    constructor and fails to call the base class constructor, a
    program using the class may fail, but it will not crash the
    interpreter. On the other hand, an extension subclass that
    overrides a constructor in an extension base class must call the
    extension base class constructor or risk crashing the interpreter.
    This is because the base class constructor may set C pointers that,
    if not set properly, will cause the interpreter to crash when
    accessed.  This is the case with the 'MultiMapping' extension base
    class shown in the example above.

    If no base class constructor is provided, extension class instance
    memory will be initialized to 0.  It is a good idea to design
    extension base classes so that instance methods check for
    uninitialized memory and perform initialialization if necessary.
    This was not done above to simplify the example.

  Overriding methods inherited from Python base classes

    A problem occurs when trying to overide methods inherited from
    Python base classes.  Consider the following example::

      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
	  self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
	  Spam.__init__(self,name)
	  self.favorite_color=favorite_color

    This implementation will fail when an 'ECSpam' object is
    instantiated.  The problem is that 'ECSpam.__init__' calls
    'Spam.__init__', and 'Spam.__init__' can only be called with a
    Python instance (an object of type '"instance"') as the first
    argument.  The first argument passed to 'Spam.__init__' will be an
    'ECSpam' instance (an object of type 'ECSPam').

    To overcome this problem, extension classes provide a class method
    'inheritedAttribute' that can be used to obtain an inherited
    attribute that is suitable for calling with an extension class
    instance.  Using the 'inheritedAttribute' method, the above
    example can be rewritten as::

      from ExtensionClass import Base

      class Spam:

        def __init__(self, name):
	  self.name=name

      class ECSpam(Base, Spam):

        def __init__(self, name, favorite_color):
	  ECSpam.inheritedAttribute('__init__')(self,name)
	  self.favorite_color=favorite_color

    This isn't as pretty but does provide the desired result.

  New class and instance semantics

    Context Wrapping

      It is sometimes useful to be able to wrap up an object together
      with a containing object.  I call this "context wrapping"
      because an object is accessed in the context of the object it is
      accessed through.

      We have found many applications for this, including:

        - User-defined method objects, 

	- "Acquisition":Acquisition.html, and

	- Computed attributes
  
      User-defined method objects
      
	Python classes wrap Python function attributes into methods.  When a
	class has a function attribute that is accessed as an instance
	attribute, a method object is created and returned that contains
	references to the original function and instance.  When the method
	is called, the original function is called with the instance as the
	first argument followed by any arguments passed to the method.
    
	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 '__of__' method, then when the
	attribute is accessed through an instance, it's '__of__' method
	will be called to create a bound method.

	Consider the following example::
      
	  import ExtensionClass
	  
	  class CustomMethod(ExtensionClass.Base):
      
	    def __call__(self,ob): 
              print 'a %s was called' % ob.__class__.__name__
      
	    class wrapper:
      
	      def __init__(self,m,o): self.meth, self.ob=m,o
      
	      def __call__(self): self.meth(self.ob)
      
	    def __of__(self,o): return self.wrapper(self,o)
	  
	  class bar(ExtensionClass.Base):
	    hi=CustomMethod()
	  
	  x=bar()
	  hi=x.hi()
      
	Note that 'ExtensionClass.Base' is a base extension class that
	provides very basic ExtensionClass behavior. 
      
	When run, this program outputs: 'a bar was called'.

      Computed Attributes

	It is not uncommon to wish to expose information via the
	attribute interface without affecting implementation data
	structures.  One can use a custom '__getattr__' method to
	implement computed attributes, however, this can be a bit
	cumbersome and can interfere with other uses of '__getattr__',
	such as for persistence.

	The '__of__' 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 '__of__' method is called:

	  import ExtensionClass
	
	  class ComputedAttribute(ExtensionClass.Base):
	
	    def __init__(self, func): self.func=func
	
	    def __of__(self, parent): return self.func(parent)
	
	Then we can use this class to create computed attributes.  In the
	example below, we create a computed attribute, 'radius':
	
	  from math import sqrt
	
	  class Point(ExtensionClass.Base):
	
	    def __init__(self, x, y): self.x, self.y = x, y
	
	    radius=ComputedAttribute(lambda self: sqrt(self.x**2+self.y**2))
	
	which we can use just like an ordinary attribute:
	
	  p=Point(2,2)
	  print p.radius

    Overriding method calls

      Normally, when a method is called, the function wrapped by the
      method is called directly by the method.  In some cases, it is
      useful for user-defined logic to participate in the actual
      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, '__call_method__', then this method will be called to
      call the functions (or other callable object) wrapped by the
      method.  The method. '__call_method__' should provide the same
      interface as provided by the Python builtin 'apply' function.

      For example, consider the expression: 'x.meth(arg1, arg2)'.  The
      expression is evaluated by first computing a method object that
      wraps 'x' and the attribute of 'x' stored under the name 'meth'.
      Assuming that 'x' has a '__call_method__' method defined, then
      the '__call_method__' method of 'x' will be called with two
      arguments, the attribute of 'x' stored under the name 'meth',
      and a tuple containing 'x', 'arg1', and 'arg2'.

      To see how this feature may be used, see the Python module,
      'Syn.py', which is included in the ExtensionClass distribution.
      This module provides a mix-in class that provides Java-like
      "synchonized" classes that limit access to their methods to one
      thread at a time.

      An interesting application of this mechanism would be to
      implement interface checking on method calls.

    Method attributes

      Methods of ExtensionClass instances can have user-defined
      attributes, which are stored in their associated instances.

      For example::

        class C(ExtensionClass.Base):

	  def get_secret(self):
	    "Get a secret"
	    ....

	c=C()

	c.f.__roles__=['Trusted People']

	print c.f.__roles__ # outputs ['Trusted People']
	print c.f__roles__  # outputs ['Trusted People']

	print C.f.__roles__ # fails, unbound method

      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 '__name__' attribute and the attribute name.
      Attributes cannot be set on unbound methods.

    Class initialization

      Normal Python class initialization is similar to but subtley
      different from instance initialization.  An instance '__init__'
      function is called on an instance immediately *after* it is
      created.  An instance '__init__' 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 *before* the class is created.  This means
      that the code in a class statement cannot use class attributes,
      like '__bases__', or pass the class to functions.

      Extension classes provide a mechanism for specifying code to be
      run *after* a class has been created.  If a class or one of it's
      base classes defines a '__class_init__' 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, *not* an
      instance of the class.

  Useful macros defined in ExtensionClass.h

    A number of useful macros are defined in ExtensionClass.h.
    These are documented in 'ExtensionClass.h'.

  Pickleability

    Classes created with ExtensionClass, including extension base
    classes are automatically pickleable.  The usual gymnastics
    necessary to pickle 'non-standard' types are not necessray for
    types that have been modified to be extension base classes.

  Status

    The current release of the extension class module is "1.1",
    http://www.digicool.com/releases/ExtensionClass/ExtensionClass-1.1.tar.gz.
    The core implementation has less than four thousand lines of code,
    including comments.  This release requires Python 1.4 or higher.

    To find out what's changed in this release, see the
    "release notes":release.html.

    "Installation instructions":Installation.html, are provided.

  Issues
  
    There are a number of issues that came up in the course of this work
    and that deserve mention.
  
    - In Python 1.4, the class extension mechanism described in [4] required
      that the first superclass in a list of super-classes must be of the
      extended class type.  This may not be convenient if mix-in
      behavior is desired.  If a list of base classes starts with a
      standard python class, but includes an extension class, then an
      error was raised.  It would be more useful if, when a list of base
      classes contains one or more objects that are not python classes,
      the first such object was used to control the extended class
      definition.  To get around this, the 'ExtensionClass' module exports
      a base extension class, 'Base', that can be used as the first base
      class in a list of base classes to assure that an extension
      subclass is created.

      Python 1.5 allows the class extension even if the first non-class
      object in the list of base classes is not the first object in
      the list.  This issue appears to go away in Python 1.5, however,
      the restriction that the first non-class object in a list of
      base classes must be the first in the list may reappear in later
      versions of Python.
  
    - Currently, only one base extension class can define any data in
      C.  The data layout of subclasses-instances is the same as for the
      base class that defines data in C, except that the data structure
      is extended to hold an instance dictionary.  The data structure
      begins with a standard python header, and extension methods expect
      the C instance data to occur immediately after the object header.  If
      two or more base classes defined C data, the methods for the
      different base classes would expect their data to be in the same
      location. A solution might be to allocate base class instances and
      store pointers to these instances in the subclass data structure.
      The method binding mechanism would have to be a more complicated
      to make sure that methods were bound to the correct base data
      structure.  Alternatively, the signature of C methods could be
      expanded to allow pointers to expected class data to be passed
      in addition to object pointers.

    - There is currently no support for sub-classing in C, beyond that
      provided by method chains.
  
    - Rules for mixed-type arithmetic are different for python class
      instances than they are for extension type instances.  Python
      classes can define right and left versions of numeric binary
      operators, or they can define a coercion operator for converting
      binary operator operands to a common type.  For extension types,
      only the latter, coercion-based, approach is supported.  The
      coercion-based approach does not work well for many data types for
      which coercion rules depend on the operator.  Because extension
      classes are based on extension types, they are currently limited
      to the coercion-based approach.  It should be possible to
      extend the extension class implementation to allow both types of
      mixed-type arithmetic control.
  
    - I considered making extension classes immutable, meaning that
      class attributes could not be set after class creation.  I also
      considered making extension subclasses cache inherited
      attributes.  Both of these are related and attractive for some
      applications, however, I decided that it would be better to retain
      standard class instance semantics and provide these features as
      options at a later time.
  
    - The extension class module defines new method types to bind C and
      python methods to extension class instances.  It would be useful
      for these method objects to provide access to function call
      information, such as the number and names of arguments and the
      number of defaults, by parsing extension function documentation
      strings.
  
  Applications
  
    Aside from test and demonstration applications, the extension class
    mechanism has been used to provide an extension-based implementation
    of the persistence mechanism described in [1].  We have developed
    this further to provide features such as automatic deactivation of
    objects not used after some period of time and to provide more
    efficient persistent-object cache management.

    Acquisition has been heavily used in our recent products.
    Synchonized classes have also been used in recent products.
  
  Summary
    
    The extension-class mechanism described here provides a way to add
    class services to extension types.  It allows:
  
      - Sub-classing extension classes in Python,
  
      - Construction of extension class instances by calling extension
	classes,
  
      - Extension classes to provide meta-data, such as unbound methods
	and their documentation string.
  
    In addition, the extension class module provides a relatively
    concise example of the use of mechanisms that were added to Python
    to support MESS [6], and that were described at the fourth Python
    Workshop [4].  It is hoped that this will spur research in improved
    and specialized models for class implementation in Python.
  
  References
  
.. [1] Fulton, J., "Providing Persistence for World-Wide-Web Applications", 
 http://www.digicool.com/papers/Persistence.html,
 Proceedings of the 5th Python Workshop.
   
.. [2] Page, R. and Cropper, S., "Document Template", 
 http://www.digicool.com/papers/DocumentTemplate.html,
 Proceedings of the 5th Python Workshop.
   
.. [3] Beaudry, D., "Deriving Built-In Classes in Python", 
 http://www.python.org/workshops/1994-11/BuiltInClasses/BuiltInClasses_1.html,
 Proceedings of the First International Python Workshop.
   
.. [4] Van Rossum, G., "Don Beaudry Hack - MESS", 
 http://www.python.org/workshops/1996-06/notes/thursday.html,
 presented in the Developer's Future Enhancements session of the 
 4th Python Workshop. 
   
.. [5] Fulton, J., "Meta-Type Object",
 http://www.digicool.com/jim/MetaType.c,
 This is a small proposal, the text of which is contained in a 
 sample implementation source file,  
   
.. [6] Beaudry, D., and Ascher, D., "The Meta-Extension Set", 
 http://starship.skyport.net/~da/mess/.


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/InnerLinks.ref ===
<html>
<head>
<title>This is the InnerLinkTest</title>
</head>
<body>
<h1>This is the InnerLinkTest</h1>
<p>  see also <a href="#ref1">[1]</a> and <a href="#ref2">[2]</a></p>
<p>  <a name="ref1">[1]</a> "Zope Book" by Amos Lattmeier and Michel Pelletier</p>
<p>  <a name="ref2">[2]</a> "Python Book" by Guido van Rossum</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/InnerLinks.stx ===
This is the InnerLinkTest


  see also [1] and [2]


  .. [1] "Zope Book" by Amos Lattmeier and Michel Pelletier

  .. [2] "Python Book" by Guido van Rossum
  


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/Links.ref ===
<html>
<head>
<title>This is LinkTest</title>
</head>
<body>
<h1>This is LinkTest</h1>

<ul>
<li>please click <a href="/Members/Zope">here</a></li>
<li>please click <a href="/Members/Zope?a=b&c=d%20blabla">here</a></li>
<li>please click <a href="http://www.zope.org">here</a></li>
<li>please click <a href="http://www.zope.org/members/">here</a></li>
<li>please click <a href="http://www.zope.org:2001">here</a> </li>
<li>please click <a href="http://www.zope.org:2001/members/">here</a></li>
<li>please click <a href="http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test">here</a> </li>
<li>please click <a href="http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test">here</a> </li>
<li>please click <a href="http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test">here</a> </li>

</ul>
<p>  And now a paragraph with <a href="http://www.zope-rocks.org">Link 1</a> and 
  <a href="http://www.zope-is-kewl.com">Link 2</a>  and <a href="http://www.freshmeat.net">one more link - yeah.</a></p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/Links.stx ===
This is LinkTest

  - please click "here":/Members/Zope

  - please click "here":/Members/Zope?a=b&c=d%20blabla

  - please click "here":http://www.zope.org

  - please click "here":http://www.zope.org/members/

  - please click "here":http://www.zope.org:2001 
 
  - please click "here":http://www.zope.org:2001/members/

  - please click "here":http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test 

  - please click "here":http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test 

  - please click "here", http://www.zope.org:2001/%20/Members/zope?a=222&b=213&_xc=just%20a%20test 


  And now a paragraph with "Link 1":http://www.zope-rocks.org and 
  "Link 2":http://www.zope-is-kewl.com  and "one more link - yeah.":http://www.freshmeat.net



=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/MultiMapping.ref ===
<html>
<head>
<title>Example: MultiMapping objects</title>
</head>
<body>
<h1>Example: MultiMapping objects</h1>
<p>  <a href="COPYRIGHT.html">Copyright (C) 1996-1998, Digital Creations</a>.</p>
<p>  As an example, consider an extension class that implements a
  "MultiMapping". A multi-mapping is an object that encapsulates 0
  or more mapping objects.  When an attempt is made to lookup an
  object, the encapsulated mapping objects are searched until an
  object is found.</p>
<p>  Consider an implementation of a MultiMapping extension type,
  without use of the extension class mechanism:
<pre>
    #include "Python.h"

    #define UNLESS(E) if(!(E))

    typedef struct {
        PyObject_HEAD
        PyObject *data;
    } MMobject;

    staticforward PyTypeObject MMtype;

    static PyObject *
    MM_push(MMobject *self, PyObject *args){
        PyObject *src;
        UNLESS(PyArg_ParseTuple(args, "O", &amp;src)) return NULL;
        UNLESS(-1 != PyList_Append(self-&gt;data,src)) return NULL;
        Py_INCREF(Py_None);
        return Py_None;
    }

    static PyObject *
    MM_pop(MMobject *self, PyObject *args){
        long l;
        PyObject *r;
        static PyObject *emptyList=0;

        UNLESS(emptyList) UNLESS(emptyList=PyList_New(0)) return NULL;
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(-1 != (l=PyList_Size(self-&gt;data))) return NULL;
        l--;
        UNLESS(r=PySequence_GetItem(self-&gt;data,l)) return NULL;
        UNLESS(-1 != PyList_SetSlice(self-&gt;data,l,l+1,emptyList)) goto err;
        return r;
    err:
        Py_DECREF(r);
        return NULL;
    }

    static struct PyMethodDef MM_methods[] = {
        {"push", (PyCFunction) MM_push, 1,
         "push(mapping_object) -- Add a data source"},
        {"pop",  (PyCFunction) MM_pop,  1,
         "pop() -- Remove and return the last data source added"}, 
        {NULL,              NULL}           /* sentinel */
    };

    static PyObject *
    newMMobject(PyObject *ignored, PyObject *args){
        MMobject *self;

        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(self = PyObject_NEW(MMobject, &amp;MMtype)) return NULL;
        UNLESS(self-&gt;data=PyList_New(0)) goto err;
        return (PyObject *)self;
    err:
        Py_DECREF(self);
        return NULL;
    }

    static void
    MM_dealloc(MMobject *self){
        Py_XDECREF(self-&gt;data);
        PyMem_DEL(self);
    }

    static PyObject *
    MM_getattr(MMobject *self, char *name){
        return Py_FindMethod(MM_methods, (PyObject *)self, name);
    }

    static int
    MM_length(MMobject *self){
        long l=0, el, i;
        PyObject *e=0;

        UNLESS(-1 != (i=PyList_Size(self-&gt;data))) return -1;
        while(--i &gt;= 0)
          {
            e=PyList_GetItem(self-&gt;data,i);
            UNLESS(-1 != (el=PyObject_Length(e))) return -1;
            l+=el;
          }
        return l;
    }

    static PyObject *
    MM_subscript(MMobject *self, PyObject *key){
        long i;
        PyObject *e;

        UNLESS(-1 != (i=PyList_Size(self-&gt;data))) return NULL;
        while(--i &gt;= 0)
          {
            e=PyList_GetItem(self-&gt;data,i);
            if(e=PyObject_GetItem(e,key)) return e;
            PyErr_Clear();
          }
        PyErr_SetObject(PyExc_KeyError,key);
        return NULL;
    }

    static PyMappingMethods MM_as_mapping = {
              (inquiry)MM_length,           /*mp_length*/
              (binaryfunc)MM_subscript,             /*mp_subscript*/
              (objobjargproc)NULL,          /*mp_ass_subscript*/
    };

    /* -------------------------------------------------------- */

    static char MMtype__doc__[] = 
    "MultiMapping -- Combine multiple mapping objects for lookup"
    ;

    static PyTypeObject MMtype = {
              PyObject_HEAD_INIT(&amp;PyType_Type)
              0,                            /*ob_size*/
              "MultMapping",                        /*tp_name*/
              sizeof(MMobject),             /*tp_basicsize*/
              0,                            /*tp_itemsize*/
              /* methods */
              (destructor)MM_dealloc,               /*tp_dealloc*/
              (printfunc)0,                 /*tp_print*/
              (getattrfunc)MM_getattr,      /*tp_getattr*/
              (setattrfunc)0,                       /*tp_setattr*/
              (cmpfunc)0,                   /*tp_compare*/
              (reprfunc)0,                  /*tp_repr*/
              0,                            /*tp_as_number*/
              0,                            /*tp_as_sequence*/
              &amp;MM_as_mapping,                       /*tp_as_mapping*/
              (hashfunc)0,                  /*tp_hash*/
              (ternaryfunc)0,                       /*tp_call*/
              (reprfunc)0,                  /*tp_str*/

              /* Space for future expansion */
              0L,0L,0L,0L,
              MMtype__doc__ /* Documentation string */
    };

    static struct PyMethodDef MultiMapping_methods[] = {
        {"MultiMapping", (PyCFunction)newMMobject, 1,
         "MultiMapping() -- Create a new empty multi-mapping"},
        {NULL,              NULL}           /* sentinel */
    };

    void
    initMultiMapping(){
        PyObject *m;

        m = Py_InitModule4(
            "MultiMapping", MultiMapping_methods,
              "MultiMapping -- Wrap multiple mapping objects for lookup",
              (PyObject*)NULL,PYTHON_API_VERSION);

        if (PyErr_Occurred()) 
           Py_FatalError("can't initialize module MultiMapping");
    }
</pre>
</p>
<p>  This module defines an extension type, <code>MultiMapping</code>, and exports a
  module function, <code>MultiMapping</code>, that creates <code>MultiMapping</code>
  Instances. The type provides two methods, <code>push</code>, and <code>pop</code>, for
  adding and removing mapping objects to the multi-mapping.
  The type provides mapping behavior, implementing mapping length
  and subscript operators but not mapping a subscript assignment
  operator.</p>
<p>  Now consider an extension class implementation of MultiMapping
  objects:
<pre>
    #include "Python.h"
    #include "ExtensionClass.h"

    #define UNLESS(E) if(!(E))

    typedef struct {
        PyObject_HEAD
        PyObject *data;
    } MMobject;

    staticforward PyExtensionClass MMtype;

    static PyObject *
    MM_push(self, args)
              MMobject *self;
              PyObject *args;
    {
        PyObject *src;
        UNLESS(PyArg_ParseTuple(args, "O", &amp;src)) return NULL;
        UNLESS(-1 != PyList_Append(self-&gt;data,src)) return NULL;
        Py_INCREF(Py_None);
        return Py_None;
    }

    static PyObject *
    MM_pop(self, args)
              MMobject *self;
              PyObject *args;
    {
        long l;
        PyObject *r;
        static PyObject *emptyList=0;

        UNLESS(emptyList) UNLESS(emptyList=PyList_New(0)) return NULL;
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(-1 != (l=PyList_Size(self-&gt;data))) return NULL;
        l--;
        UNLESS(r=PySequence_GetItem(self-&gt;data,l)) return NULL;
        UNLESS(-1 != PyList_SetSlice(self-&gt;data,l,l+1,emptyList)) goto err;
        return r;
    err:
        Py_DECREF(r);
        return NULL;
    }

    static PyObject *
    MM__init__(self, args)
           MMobject *self;
           PyObject *args;
    {
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(self-&gt;data=PyList_New(0)) goto err;
        Py_INCREF(Py_None);
        return Py_None;
    err:
        Py_DECREF(self);
        return NULL;
    }

    static struct PyMethodDef MM_methods[] = {
        {"__init__", (PyCFunction)MM__init__, 1,
         "__init__() -- Create a new empty multi-mapping"},
        {"push", (PyCFunction) MM_push, 1,
         "push(mapping_object) -- Add a data source"},
        {"pop",  (PyCFunction) MM_pop,  1,
         "pop() -- Remove and return the last data source added"}, 
        {NULL,              NULL}           /* sentinel */
    };

    static void
    MM_dealloc(self)
           MMobject *self;
    {
        Py_XDECREF(self-&gt;data);
        PyMem_DEL(self);
    }

    static PyObject *
    MM_getattr(self, name)
              MMobject *self;
              char *name;
    {
        return Py_FindMethod(MM_methods, (PyObject *)self, name);
    }

    static int
    MM_length(self)
              MMobject *self;
    {
        long l=0, el, i;
        PyObject *e=0;

        UNLESS(-1 != (i=PyList_Size(self-&gt;data))) return -1;
        while(--i &gt;= 0)
          {
            e=PyList_GetItem(self-&gt;data,i);
            UNLESS(-1 != (el=PyObject_Length(e))) return -1;
            l+=el;
          }
        return l;
    }

    static PyObject *
    MM_subscript(self, key)
              MMobject *self;
              PyObject *key;
    {
        long i;
        PyObject *e;

        UNLESS(-1 != (i=PyList_Size(self-&gt;data))) return NULL;
        while(--i &gt;= 0)
          {
            e=PyList_GetItem(self-&gt;data,i);
            if(e=PyObject_GetItem(e,key)) return e;
            PyErr_Clear();
          }
        PyErr_SetObject(PyExc_KeyError,key);
        return NULL;
    }

    static PyMappingMethods MM_as_mapping = {
              (inquiry)MM_length,           /*mp_length*/
              (binaryfunc)MM_subscript,             /*mp_subscript*/
              (objobjargproc)NULL,          /*mp_ass_subscript*/
    };

    /* -------------------------------------------------------- */

    static char MMtype__doc__[] = 
    "MultiMapping -- Combine multiple mapping objects for lookup"
    ;

    static PyExtensionClass MMtype = {
              PyObject_HEAD_INIT(&amp;PyType_Type)
              0,                            /*ob_size*/
              "MultMapping",                        /*tp_name*/
              sizeof(MMobject),             /*tp_basicsize*/
              0,                            /*tp_itemsize*/
              /* methods */
              (destructor)MM_dealloc,               /*tp_dealloc*/
              (printfunc)0,                 /*tp_print*/
              (getattrfunc)MM_getattr,      /*tp_getattr*/
              (setattrfunc)0,                       /*tp_setattr*/
              (cmpfunc)0,                   /*tp_compare*/
              (reprfunc)0,                  /*tp_repr*/
              0,                            /*tp_as_number*/
              0,                            /*tp_as_sequence*/
              &amp;MM_as_mapping,                       /*tp_as_mapping*/
              (hashfunc)0,                  /*tp_hash*/
              (ternaryfunc)0,                       /*tp_call*/
              (reprfunc)0,                  /*tp_str*/

              /* Space for future expansion */
              0L,0L,0L,0L,
              MMtype__doc__, /* Documentation string */
              METHOD_CHAIN(MM_methods)
    };

    static struct PyMethodDef MultiMapping_methods[] = {
        {NULL,              NULL}           /* sentinel */
    };

    void
    initMultiMapping()
    {
        PyObject *m, *d;

        m = Py_InitModule4(
            "MultiMapping", MultiMapping_methods,
            "MultiMapping -- Wrap multiple mapping objects for lookup",
            (PyObject*)NULL,PYTHON_API_VERSION);
        d = PyModule_GetDict(m);
        PyExtensionClass_Export(d,"MultiMapping",MMtype);

        if (PyErr_Occurred()) 
           Py_FatalError("can't initialize module MultiMapping");
    }
</pre>
</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 <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, <code>MM__init__</code>.  Note that this
  method does not create or return a new object.  Finally, the lines:
<pre>
    d = PyModule_GetDict(m);
    PyExtensionClass_Export(d,"MultiMapping",MMtype);
</pre>
</p>
<p>  Have been added to both initialize the extension class and to export
  it in the module dictionary.</p>
<p>  To use this module, compile, link, and import it as with any other
  extension module.  The following python code illustrates the
  module's use:
<pre>
    from MultiMapping import MultiMapping
    m=MultiMapping()
    m.push({'spam':1, 'eggs':2})
    m.push({'spam':3, 'ham':4})

    m['spam'] # returns 3
    m['ham']  # returns 4
    m['foo']  # raises a key error
</pre>
</p>
<p>  Creating the <code>MultiMapping</code> object took three steps, one to create
  an empty <code>MultiMapping</code>, and two to add mapping objects to it.  We
  might wish to simplify the process of creating MultiMapping
  objects by providing a constructor that takes source mapping
  objects as parameters.  We can do this by sub-classing MultiMapping
  in Python:
<pre>
    from MultiMapping import MultiMapping
    class ExtendedMultiMapping(MultiMapping):
        def __init__(self,*data):
          MultiMapping.__init__(self)
          for d in data: self.push(d)

    m=ExtendedMultiMapping({'spam':1, 'eggs':2}, {'spam':3, 'ham':4})

    m['spam'] # returns 3
    m['ham']  # returns 4
    m['foo']  # raises a key error
</pre>
</p>
<p>  Note that the source file included in the ExtensionClass
  distribution has numerous enhancements beyond the version shown in
  this document.</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/MultiMapping.stx ===
Example: MultiMapping objects

  "Copyright (C) 1996-1998, Digital Creations":COPYRIGHT.html.

  As an example, consider an extension class that implements a
  "MultiMapping". A multi-mapping is an object that encapsulates 0
  or more mapping objects.  When an attempt is made to lookup an
  object, the encapsulated mapping objects are searched until an
  object is found.

  Consider an implementation of a MultiMapping extension type,
  without use of the extension class mechanism::

    #include "Python.h"
    
    #define UNLESS(E) if(!(E))
    
    typedef struct {
        PyObject_HEAD
        PyObject *data;
    } MMobject;
    
    staticforward PyTypeObject MMtype;
    
    static PyObject *
    MM_push(MMobject *self, PyObject *args){
        PyObject *src;
        UNLESS(PyArg_ParseTuple(args, "O", &src)) return NULL;
        UNLESS(-1 != PyList_Append(self->data,src)) return NULL;
        Py_INCREF(Py_None);
        return Py_None;
    }
    
    static PyObject *
    MM_pop(MMobject *self, PyObject *args){
        long l;
        PyObject *r;
        static PyObject *emptyList=0;
    
        UNLESS(emptyList) UNLESS(emptyList=PyList_New(0)) return NULL;
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(-1 != (l=PyList_Size(self->data))) return NULL;
        l--;
        UNLESS(r=PySequence_GetItem(self->data,l)) return NULL;
        UNLESS(-1 != PyList_SetSlice(self->data,l,l+1,emptyList)) goto err;
        return r;
    err:
        Py_DECREF(r);
        return NULL;
    }
    
    static struct PyMethodDef MM_methods[] = {
        {"push", (PyCFunction) MM_push, 1,
         "push(mapping_object) -- Add a data source"},
        {"pop",  (PyCFunction) MM_pop,  1,
         "pop() -- Remove and return the last data source added"}, 
        {NULL,              NULL}           /* sentinel */
    };
    
    static PyObject *
    newMMobject(PyObject *ignored, PyObject *args){
        MMobject *self;
              
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(self = PyObject_NEW(MMobject, &MMtype)) return NULL;
        UNLESS(self->data=PyList_New(0)) goto err;
        return (PyObject *)self;
    err:
        Py_DECREF(self);
        return NULL;
    }
    
    static void
    MM_dealloc(MMobject *self){
        Py_XDECREF(self->data);
        PyMem_DEL(self);
    }
    
    static PyObject *
    MM_getattr(MMobject *self, char *name){
        return Py_FindMethod(MM_methods, (PyObject *)self, name);
    }
    
    static int
    MM_length(MMobject *self){
        long l=0, el, i;
        PyObject *e=0;
    
        UNLESS(-1 != (i=PyList_Size(self->data))) return -1;
        while(--i >= 0)
          {
            e=PyList_GetItem(self->data,i);
            UNLESS(-1 != (el=PyObject_Length(e))) return -1;
            l+=el;
          }
        return l;
    }
    
    static PyObject *
    MM_subscript(MMobject *self, PyObject *key){
        long i;
        PyObject *e;
    
        UNLESS(-1 != (i=PyList_Size(self->data))) return NULL;
        while(--i >= 0)
          {
            e=PyList_GetItem(self->data,i);
            if(e=PyObject_GetItem(e,key)) return e;
            PyErr_Clear();
          }
        PyErr_SetObject(PyExc_KeyError,key);
        return NULL;
    }
    
    static PyMappingMethods MM_as_mapping = {
              (inquiry)MM_length,           /*mp_length*/
              (binaryfunc)MM_subscript,             /*mp_subscript*/
              (objobjargproc)NULL,          /*mp_ass_subscript*/
    };
    
    /* -------------------------------------------------------- */
    
    static char MMtype__doc__[] = 
    "MultiMapping -- Combine multiple mapping objects for lookup"
    ;
    
    static PyTypeObject MMtype = {
              PyObject_HEAD_INIT(&PyType_Type)
              0,                            /*ob_size*/
              "MultMapping",                        /*tp_name*/
              sizeof(MMobject),             /*tp_basicsize*/
              0,                            /*tp_itemsize*/
              /* methods */
              (destructor)MM_dealloc,               /*tp_dealloc*/
              (printfunc)0,                 /*tp_print*/
              (getattrfunc)MM_getattr,      /*tp_getattr*/
              (setattrfunc)0,                       /*tp_setattr*/
              (cmpfunc)0,                   /*tp_compare*/
              (reprfunc)0,                  /*tp_repr*/
              0,                            /*tp_as_number*/
              0,                            /*tp_as_sequence*/
              &MM_as_mapping,                       /*tp_as_mapping*/
              (hashfunc)0,                  /*tp_hash*/
              (ternaryfunc)0,                       /*tp_call*/
              (reprfunc)0,                  /*tp_str*/
    
              /* Space for future expansion */
              0L,0L,0L,0L,
              MMtype__doc__ /* Documentation string */
    };
    
    static struct PyMethodDef MultiMapping_methods[] = {
        {"MultiMapping", (PyCFunction)newMMobject, 1,
         "MultiMapping() -- Create a new empty multi-mapping"},
        {NULL,              NULL}           /* sentinel */
    };
    
    void
    initMultiMapping(){
        PyObject *m;
    
        m = Py_InitModule4(
            "MultiMapping", MultiMapping_methods,
              "MultiMapping -- Wrap multiple mapping objects for lookup",
              (PyObject*)NULL,PYTHON_API_VERSION);
    
        if (PyErr_Occurred()) 
           Py_FatalError("can't initialize module MultiMapping");
    }

  This module defines an extension type, 'MultiMapping', and exports a
  module function, 'MultiMapping', that creates 'MultiMapping'
  Instances. The type provides two methods, 'push', and 'pop', for
  adding and removing mapping objects to the multi-mapping.
  The type provides mapping behavior, implementing mapping length
  and subscript operators but not mapping a subscript assignment
  operator.

  Now consider an extension class implementation of MultiMapping
  objects::

    #include "Python.h"
    #include "ExtensionClass.h"
    
    #define UNLESS(E) if(!(E))
    
    typedef struct {
        PyObject_HEAD
        PyObject *data;
    } MMobject;
    
    staticforward PyExtensionClass MMtype;
    
    static PyObject *
    MM_push(self, args)
              MMobject *self;
              PyObject *args;
    {
        PyObject *src;
        UNLESS(PyArg_ParseTuple(args, "O", &src)) return NULL;
        UNLESS(-1 != PyList_Append(self->data,src)) return NULL;
        Py_INCREF(Py_None);
        return Py_None;
    }
    
    static PyObject *
    MM_pop(self, args)
              MMobject *self;
              PyObject *args;
    {
        long l;
        PyObject *r;
        static PyObject *emptyList=0;
    
        UNLESS(emptyList) UNLESS(emptyList=PyList_New(0)) return NULL;
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(-1 != (l=PyList_Size(self->data))) return NULL;
        l--;
        UNLESS(r=PySequence_GetItem(self->data,l)) return NULL;
        UNLESS(-1 != PyList_SetSlice(self->data,l,l+1,emptyList)) goto err;
        return r;
    err:
        Py_DECREF(r);
        return NULL;
    }
    
    static PyObject *
    MM__init__(self, args)
           MMobject *self;
           PyObject *args;
    {
        UNLESS(PyArg_ParseTuple(args, "")) return NULL;
        UNLESS(self->data=PyList_New(0)) goto err;
        Py_INCREF(Py_None);
        return Py_None;
    err:
        Py_DECREF(self);
        return NULL;
    }
    
    static struct PyMethodDef MM_methods[] = {
        {"__init__", (PyCFunction)MM__init__, 1,
         "__init__() -- Create a new empty multi-mapping"},
        {"push", (PyCFunction) MM_push, 1,
         "push(mapping_object) -- Add a data source"},
        {"pop",  (PyCFunction) MM_pop,  1,
         "pop() -- Remove and return the last data source added"}, 
        {NULL,              NULL}           /* sentinel */
    };
    
    static void
    MM_dealloc(self)
           MMobject *self;
    {
        Py_XDECREF(self->data);
        PyMem_DEL(self);
    }
    
    static PyObject *
    MM_getattr(self, name)
              MMobject *self;
              char *name;
    {
        return Py_FindMethod(MM_methods, (PyObject *)self, name);
    }
    
    static int
    MM_length(self)
              MMobject *self;
    {
        long l=0, el, i;
        PyObject *e=0;
    
        UNLESS(-1 != (i=PyList_Size(self->data))) return -1;
        while(--i >= 0)
          {
            e=PyList_GetItem(self->data,i);
            UNLESS(-1 != (el=PyObject_Length(e))) return -1;
            l+=el;
          }
        return l;
    }
    
    static PyObject *
    MM_subscript(self, key)
              MMobject *self;
              PyObject *key;
    {
        long i;
        PyObject *e;
    
        UNLESS(-1 != (i=PyList_Size(self->data))) return NULL;
        while(--i >= 0)
          {
            e=PyList_GetItem(self->data,i);
            if(e=PyObject_GetItem(e,key)) return e;
            PyErr_Clear();
          }
        PyErr_SetObject(PyExc_KeyError,key);
        return NULL;
    }
    
    static PyMappingMethods MM_as_mapping = {
              (inquiry)MM_length,           /*mp_length*/
              (binaryfunc)MM_subscript,             /*mp_subscript*/
              (objobjargproc)NULL,          /*mp_ass_subscript*/
    };
    
    /* -------------------------------------------------------- */
    
    static char MMtype__doc__[] = 
    "MultiMapping -- Combine multiple mapping objects for lookup"
    ;
    
    static PyExtensionClass MMtype = {
              PyObject_HEAD_INIT(&PyType_Type)
              0,                            /*ob_size*/
              "MultMapping",                        /*tp_name*/
              sizeof(MMobject),             /*tp_basicsize*/
              0,                            /*tp_itemsize*/
              /* methods */
              (destructor)MM_dealloc,               /*tp_dealloc*/
              (printfunc)0,                 /*tp_print*/
              (getattrfunc)MM_getattr,      /*tp_getattr*/
              (setattrfunc)0,                       /*tp_setattr*/
              (cmpfunc)0,                   /*tp_compare*/
              (reprfunc)0,                  /*tp_repr*/
              0,                            /*tp_as_number*/
              0,                            /*tp_as_sequence*/
              &MM_as_mapping,                       /*tp_as_mapping*/
              (hashfunc)0,                  /*tp_hash*/
              (ternaryfunc)0,                       /*tp_call*/
              (reprfunc)0,                  /*tp_str*/
    
              /* Space for future expansion */
              0L,0L,0L,0L,
              MMtype__doc__, /* Documentation string */
              METHOD_CHAIN(MM_methods)
    };
    
    static struct PyMethodDef MultiMapping_methods[] = {
        {NULL,              NULL}           /* sentinel */
    };
    
    void
    initMultiMapping()
    {
        PyObject *m, *d;
    
        m = Py_InitModule4(
            "MultiMapping", MultiMapping_methods,
            "MultiMapping -- Wrap multiple mapping objects for lookup",
            (PyObject*)NULL,PYTHON_API_VERSION);
        d = PyModule_GetDict(m);
        PyExtensionClass_Export(d,"MultiMapping",MMtype);
    
        if (PyErr_Occurred()) 
           Py_FatalError("can't initialize module MultiMapping");
    }

  This version includes 'ExtensionClass.h'.  The two declarations of
  'MMtype' have been changed from 'PyTypeObject' to 'PyExtensionClass'.
  The 'METHOD_CHAIN' macro has been used to add methods to the end of
  the definition for 'MMtype'.  The module function, newMMobject has
  been replaced by the 'MMtype' method, 'MM__init__'.  Note that this
  method does not create or return a new object.  Finally, the lines::

    d = PyModule_GetDict(m);
    PyExtensionClass_Export(d,"MultiMapping",MMtype);

  Have been added to both initialize the extension class and to export
  it in the module dictionary.

  To use this module, compile, link, and import it as with any other
  extension module.  The following python code illustrates the
  module's use::

    from MultiMapping import MultiMapping
    m=MultiMapping()
    m.push({'spam':1, 'eggs':2})
    m.push({'spam':3, 'ham':4})

    m['spam'] # returns 3
    m['ham']  # returns 4
    m['foo']  # raises a key error

  Creating the 'MultiMapping' object took three steps, one to create
  an empty 'MultiMapping', and two to add mapping objects to it.  We
  might wish to simplify the process of creating MultiMapping
  objects by providing a constructor that takes source mapping
  objects as parameters.  We can do this by sub-classing MultiMapping
  in Python::

    from MultiMapping import MultiMapping
    class ExtendedMultiMapping(MultiMapping):
        def __init__(self,*data):
          MultiMapping.__init__(self)
          for d in data: self.push(d)

    m=ExtendedMultiMapping({'spam':1, 'eggs':2}, {'spam':3, 'ham':4})

    m['spam'] # returns 3
    m['ham']  # returns 4
    m['foo']  # raises a key error

  Note that the source file included in the ExtensionClass
  distribution has numerous enhancements beyond the version shown in
  this document.


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/create_referencesfiles.py ===
##############################################################################
#
# Copyright (c) 2001 Zope Corporation and Contributors. All Rights Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.0 (ZPL).  A copy of the ZPL should accompany this distribution.
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
# FOR A PARTICULAR PURPOSE
#
##############################################################################


import os,sys
from StructuredText.StructuredText import HTML


if len(sys.argv)>1:
    files = sys.argv[1:]
else:
    files = os.listdir('.')
    files = filter(lambda x: x.endswith('.stx'), files)


for f in files:

    data = open(f,'r').read()
    html = HTML(data)

    outfile = f.replace('.stx','.ref')
    open(outfile,'w').write(html)


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/examples.ref ===
<html>
<head>
<title>Small Trials for Structured Text Formatting</title>
</head>
<body>
<h1>Small Trials for Structured Text Formatting</h1>
<p>  This paragraph should be preceded by a level 1 header.  It should
  not, itself, be made into a header, just a regular paragraph.</p>
<p>  Here are a few presentation styles, in a list <a href="#ref1">[1]</a>:</p>

<ul>
<li>A word: <em>emphasized</em>.</li>
<li>A word: <u>underlined</u>.</li>
<li>A word <strong>strong</strong>.</li>
<li>An inline example: <code>1+2</code>.</li>
<li>Another example with a different format:
    ``x='spam''' or ``y='spam''' or ``<dtml-var spam>'<code>.</code><p>    We can use expressions in the DTML var tag as 
    in ``<dtml-var "x+'.txt'">''</p>
</li>
<li>A mult-line example:
<pre>
     blah

     *foo bar*

     &lt;dtml-var yeha&gt;
</pre>
</li>

</ul>
<p><a name="ref1">[1]</a> (The referring text should be a paragraph, not a header, and
should contain a reference to this footnote, footnote "<a href="#ref1">[1]</a>".)<p>  Some hrefs, in a definition list:</p>
<dl>
<dt>  <u>Regular</u></dt>
<dd><a href="http://www.zope.org">http://www.zope.org/</a></dd>
<dt>  <u>W/trailing punctuation</u></dt>
<dd><a href="http://www.zope.org">http://www.zope.org/</a>.</dd>
<dt>  <u>W protocol implicit</u></dt>
<dd><a href=":locallink">locallink</a></dd>
<dt>  <u>W protocol implicit</u>, alternate</dt>
<dd>"locallink", :locallink</dd>
</dl>
<p>  |||| A Simple Two-column Table ||
  || Column A || Column B ||
  || Apples   || Oranges  ||</p>
</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/examples.stx ===
Small Trials for Structured Text Formatting

  This paragraph should be preceded by a level 1 header.  It should
  not, itself, be made into a header, just a regular paragraph.

  Here are a few presentation styles, in a list [1]:

  - A word: *emphasized*.

  - A word: _underlined_.

  - A word **strong**.
 
  - An inline example: '1+2'.

  - Another example with a different format:
    ``x='spam''' or ``y='spam''' or ``<dtml-var spam>''.'

    We can use expressions in the DTML var tag as 
    in ``<dtml-var "x+'.txt'">''

  - A mult-line example::

     blah

     *foo bar*

     <dtml-var yeha>


.. [1] (The referring text should be a paragraph, not a header, and
should contain a reference to this footnote, footnote "[1]".)

  Some hrefs, in a definition list:

  _Regular_ -- "http://www.zope.org/":http://www.zope.org

  _W/trailing punctuation_ -- "http://www.zope.org/":http://www.zope.org.

  _W protocol implicit_ -- "locallink"::locallink

  _W protocol implicit_, alternate -- "locallink", :locallink

  |||| A Simple Two-column Table ||
  || Column A || Column B ||
  || Apples   || Oranges  ||



=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/examples1.ref ===
<html>
<head>
<title>Test</title>
</head>
<body>
<h1>Test</h1>
<p>  For instance:
<pre>
    &lt;table border="0"&gt;
      &lt;tr&gt;&lt;td&gt;blabla&lt;/td&gt;&lt;/tr&gt;
    &lt;/table&gt;
</pre>
</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/examples1.stx ===
Test
 
  For instance::
    
    <table border="0">
      <tr><td>blabla</td></tr>
    </table>




=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/index.ref ===
<html>
<head>
<title>Extension Class</title>
</head>
<body>
<h1>Extension Class</h1>
<p>    <a href="COPYRIGHT.html">Copyright (C) 1996-1998, Digital Creations</a>.</p>
<p>    A lightweight mechanism has been developed for making Python
    extension types more class-like.  Classes can be developed in an
    extension language, such as C or C++, and these classes can be
    treated like other python classes:</p>

<ul>
<li>They can be sub-classed in python,</li>
<li>They provide access to method documentation strings, and</li>
<li>They can be used to directly create new instances.</li>

</ul>
<p>    Extension classes provide additional extensions to class and
    instance semantics, including:</p>

<ul>
<li>A protocol for accessing subobjects "in the context of" their
      containers.  This is used to implement custom method types
      and <a href="Acquisition.html">environmental acquisition</a>.</li>
<li>A protocol for overriding method call semantics.  This is used
      to implement "synchonized" classes and could be used to
      implement argument type checking.</li>
<li>A protocol for class initialization that supports execution of a
      special <code>__class_init__</code> method after a class has been
      initialized. </li>

</ul>
<p>    Extension classes illustrate how the Python class mechanism can be
    extended and may provide a basis for improved or specialized class
    models. </p>
<h2>  Releases</h2>
<p>    The current release is <a href="ExtensionClass-1.2.tar.gz">1.2</a>,
    To find out what's changed in this release,
    see the <a href="release.html">release notes</a>.</p>
<p>    Documentation is available <a href="ExtensionClass.html">on-line</a>.</p>
<h3>  Windows Binaries</h3>
<p>    A win32 binary release, <a href="ec12.zip">ec12.zip</a>, is available.  This
    release includes all of the ExtensionClass modules built as 
    Windows extension modules (.pyd) files.  These were built for
    Python 1.5.1 using Microsoft Visual C++ 5.0 in "Release" mode.</p>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/index.stx ===

Extension Class
  
    "Copyright (C) 1996-1998, Digital Creations":COPYRIGHT.html.

    A lightweight mechanism has been developed for making Python
    extension types more class-like.  Classes can be developed in an
    extension language, such as C or C++, and these classes can be
    treated like other python classes:
  
    - They can be sub-classed in python,
  
    - They provide access to method documentation strings, and
  
    - They can be used to directly create new instances.
  
    Extension classes provide additional extensions to class and
    instance semantics, including:

    - A protocol for accessing subobjects "in the context of" their
      containers.  This is used to implement custom method types
      and "environmental acquisition":Acquisition.html.

    - A protocol for overriding method call semantics.  This is used
      to implement "synchonized" classes and could be used to
      implement argument type checking.

    - A protocol for class initialization that supports execution of a
      special '__class_init__' method after a class has been
      initialized. 
  
    Extension classes illustrate how the Python class mechanism can be
    extended and may provide a basis for improved or specialized class
    models. 

  Releases

    The current release is "1.2":ExtensionClass-1.2.tar.gz,
    To find out what's changed in this release,
    see the "release notes":release.html.

    Documentation is available "on-line":ExtensionClass.html.

  Windows Binaries

    A win32 binary release, "ec12.zip":ec12.zip, is available.  This
    release includes all of the ExtensionClass modules built as 
    Windows extension modules (.pyd) files.  These were built for
    Python 1.5.1 using Microsoft Visual C++ 5.0 in "Release" mode.

    



=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/table.ref ===
<html>
<body>
<table border="1" cellpadding="2">
<tr>
<th colspan="1" align="left" valign="middle"><p> Function  </p>
</th>
<th colspan="1" align="left" valign="middle"><p>  Documentation                       </p>
</th>
</tr>
<tr>
<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>

<ul>
<li>Blah                              </li>
<li>Blaf                              <table border="1" cellpadding="2">
<tr>
<th colspan="1" align="center" valign="top"><p>  Name   </p>
</th>
<th colspan="1" align="left" valign="middle"><p>  Favorite       
  Color          </p>
</th>
</tr>
<tr>
<td colspan="1" align="left" valign="middle"><p> Jim     </p>
</td>
<td colspan="1" align="center" valign="middle"><p>   Red           </p>
</td>
</tr>
<tr>
<td colspan="1" align="left" valign="middle"><p> John    </p>
</td>
<td colspan="1" align="center" valign="middle"><p>   Blue          </p>
</td>
</tr>
</table>
</li>

</ul>
</td>
</tr>
</table>
<table border="1" cellpadding="2">
<tr>
<td colspan="3" align="left" valign="middle"><p> This should give a row with colspan 3 </p>
</td>
</tr>
<tr>
<td colspan="1" align="left" valign="middle"><p> Col 1  </p>
</td>
<td colspan="1" align="center" valign="middle"><p>       Col 2  </p>
</td>
<td colspan="1" align="center" valign="middle"><p>        Col 3    </p>
</td>
</tr>
<tr>
<td colspan="1" align="left" valign="middle"><p> Col 1  </p>
</td>
<td colspan="2" align="center" valign="middle"><p>       Col 2                   </p>
</td>
</tr>
<tr>
<td colspan="2" align="left" valign="middle"><p> Col 1                </p>
</td>
<td colspan="1" align="center" valign="middle"><p>        Col 2    </p>
</td>
</tr>
</table>
</body>
</html>


=== Added File zopeproducts/bugtracker/browser/StructuredText/regressions/table.stx ===
|-------------------------------------------------|
| Function  | Documentation                       |
|=================================================|
| '__str__' | This method converts the            |
|           |  the object to a string.            |
|           |                                     |
|           | - Blah                              |
|           |                                     |
|           | - Blaf                              |
|           |                                     |
|           |       |--------------------------|  |
|           |       |  Name   | Favorite       |  |
|           |       |         | Color          |  |
|           |       |==========================|  |
|           |       | Jim     |  Red           |  |
|           |       |--------------------------|  |
|           |       | John    |  Blue          |  |
|           |       |--------------------------|  |
|-------------------------------------------------|



|---------------------------------------|
| This should give a row with colspan 3 |
|---------------------------------------|
| Col 1  |      Col 2  |       Col 3    |
|---------------------------------------|
| Col 1  |      Col 2                   |
|---------------------------------------|
| Col 1                |       Col 2    |
|---------------------------------------|