[Zope3-checkins] SVN: Zope3/branches/ZopeX3-3.0/src/zope/ More ReSTification and consistency changes.

Fred L. Drake, Jr. fred at zope.com
Fri Jul 16 15:28:56 EDT 2004


Log message for revision 26589:
  More ReSTification and consistency changes.


Changed:
  U   Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt
  U   Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt
  U   Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt
  U   Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt
  U   Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt
  U   Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt


-=-
Modified: Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/app/registration/README.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -76,25 +76,21 @@
 
 There are several major concepts/terms that need to be understood
 
-- Registerables
-
+Registerables
   Registerables are objects that can be registered.  They implement the
-  ``IRegisterable'' interface.
+  `IRegisterable` interface.
 
-- Registries
-
+Registries
   Registeries are objects that registerables are registered with.
   Typically, these are component-management services like the adapter
   or utility service.
 
-- Registration objects
-
+Registration objects
   Registration objects store data about registrations.  They store
   registration data and represent the relationship between registries
   and registerables.
 
-- Registration managers
-
+Registration managers
   Registration managers are containers for managing registrations.
   Registrations are stored in registration managers.  All of the
   registrations for objects stored in a site-management folder are
@@ -103,15 +99,14 @@
   this so that the registration manager is exposed as a folder tab
   rather than as an item.
 
-- Registration stack
-
+Registration stack
   Registries allow multiple registrations for the same set of
   registration parameters. At most one registration for a set of
   parameters can be active at one time, but multiple registrations are
   managed. 
 
-  Registries provide functions for looking up (``queryRegistrationsFor'')
-  or creating (``createRegistrationsFor'') registration stacks.  These
+  Registries provide functions for looking up (`queryRegistrationsFor()`)
+  or creating (`createRegistrationsFor()`) registration stacks.  These
   methods are passed registration objects whos attribute values are
   used to specify the desired registration stacks.
 
@@ -120,13 +115,12 @@
   by the uttility, and the utility name.  For a given interface and
   name, the utility service may have multiple ustility
   registrations. It uses a registration stack to store these. We can
-  get the registration stack by calling ``queryRegistrationsFor'' with
+  get the registration stack by calling `queryRegistrationsFor()` with
   a registration object that has the desired interface and name.  The
   registration object passed need not be in in the stack. It is used
   soley to provide the parameters.  
 
-- Registered
-
-  The interface ``IRegistered'' provides storage and access to the
+Registered
+  The interface `IRegistered` provides storage and access to the
   registrations for a registerable.  When we make a registration, we
   refer to it in a registration stack and in the registered object.

Modified: Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/event/README.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -14,14 +14,16 @@
 The package has a list of subscribers.  Application code can manage
 subscriptions by manipulating this list.  For the examples here, we'll
 save the current contents away and empty the list. We'll restore the
-contents when we're done with out examples.
+contents when we're done with our examples.
 
+::
+
   >>> import zope.event
   >>> old_subscribers = zope.event.subscribers[:]
   >>> del zope.event.subscribers[:]
 
 The package provides a `notify` function, which is used to
-notify subscribers that something has happened:
+notify subscribers that something has happened::
 
   >>> class MyEvent:
   ...     pass
@@ -30,18 +32,18 @@
   >>> zope.event.notify(event)
 
 The notify function is called with a single object, which we call an
-event.  Any object will do:
+event.  Any object will do::
 
   >>> zope.event.notify(None)
   >>> zope.event.notify(42)
 
 An extremely trivial subscription mechanism is provided. Subscribers
-are simply callback functions:
+are simply callback functions::
 
   >>> def f(event):
   ...     print 'got:', event
 
-that are put into the subscriptions list:
+that are put into the subscriptions list::
 
   >>> zope.event.subscribers.append(f)
 
@@ -57,7 +59,7 @@
   got: 42
   also got: 42
 
-To unsubscribe, simply remove a subscriber from the list:
+To unsubscribe, simply remove a subscriber from the list::
 
   >>> zope.event.subscribers.remove(f)
   >>> zope.event.notify(42)
@@ -68,6 +70,6 @@
 frameworks will install subscribers that then dispatch to other
 subscribers based on event types or data.
 
-We're done, so we'll restore the subscribers:
+We're done, so we'll restore the subscribers::
 
   >>> zope.event.subscribers[:] = old_subscribers

Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/README.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -37,23 +37,23 @@
 In the example above, we've created an interface, `IFoo`.  We
 subclassed `zope.interface.Interface`, which is an ancestor interface for
 all interfaces, much as `object` is an ancestor of all new-style
-classes [#create]_.   The interface is not a class, It's an Interface,
-an instance of `InterfaceClass`:
+classes [#create]_.   The interface is not a class, it's an Interface,
+an instance of `InterfaceClass`::
 
   >>> type(IFoo)
   <class 'zope.interface.interface.InterfaceClass'>
   
-We can ask for the interfaces documentation:
+We can ask for the interfaces documentation::
 
   >>> IFoo.__doc__
   'Foo blah blah'
 
-and it's name:
+and it's name::
 
   >>> IFoo.__name__
   'IFoo'
 
-and even it's module:
+and even it's module::
 
   >>> IFoo.__module__
   '__main__'
@@ -80,7 +80,7 @@
   methods that are not instance methods.
 
 You can access the attributes defined by an interface using mapping
-syntax:
+syntax::
 
   >>> x = IFoo['x']
   >>> type(x)
@@ -90,12 +90,12 @@
   >>> x.__doc__
   'X blah blah'
 
-You can use `in` to determine if an interface defines a name:
+You can use `in` to determine if an interface defines a name::
 
   >>> 'x' in IFoo
   True
 
-You can iterate over interfaces to get the names they define:
+You can iterate over interfaces to get the names they define::
 
   >>> names = list(IFoo)
   >>> names.sort()
@@ -103,14 +103,14 @@
   ['bar', 'x']
 
 Remember that interfaces aren't classes. You can't access attribute
-definitions as attributes of interfaces:
+definitions as attributes of interfaces::
 
   >>> IFoo.x
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
   AttributeError: 'InterfaceClass' object has no attribute 'x'
 
-Methods provide access to the method signature:
+Methods provide access to the method signature::
 
   >>> bar = IFoo['bar']
   >>> bar.getSignatureString()
@@ -146,7 +146,7 @@
 declaring interfaces.
 
 The most common way to declare interfaces is using the implements
-function in a class statement:
+function in a class statement::
 
   >>> class Foo:
   ...     zope.interface.implements(IFoo)
@@ -164,28 +164,28 @@
 In this example, we declared that `Foo` implements `IFoo`. This means
 that instances of `Foo` provide `IFoo`.  Having made this declaration,
 there are several ways we can introspect the declarations.  First, we
-can ask an interface whether it is implemented by a class:
+can ask an interface whether it is implemented by a class::
 
   >>> IFoo.implementedBy(Foo)
   True
   
-And we can ask whether an interface is provided by an object:
+And we can ask whether an interface is provided by an object::
 
   >>> foo = Foo()
   >>> IFoo.providedBy(foo)
   True
 
-Of course, `Foo` doesn't provide `IFoo`, it implements it.
+Of course, `Foo` doesn't provide `IFoo`, it implements it::
 
   >>> IFoo.providedBy(Foo)
   False
 
-We can also ask what interfaces are implemented by an object:
+We can also ask what interfaces are implemented by an object::
 
   >>> list(zope.interface.implementedBy(Foo))
   [<InterfaceClass __main__.IFoo>]
 
-It's an error to ask for interfaces implemented by a non-class:
+It's an error to ask for interfaces implemented by a non-class::
 
   >>> IFoo.implementedBy(foo)
   Traceback (most recent call last):
@@ -197,7 +197,7 @@
   ...
   TypeError: ('ImplementedBy called for non-type', Foo(None))
 
-Similarly, we can ask what interfaces are provided by an object:
+Similarly, we can ask what interfaces are provided by an object::
 
   >>> list(zope.interface.providedBy(foo))
   [<InterfaceClass __main__.IFoo>]
@@ -208,7 +208,7 @@
 we want to document what the `__init__` method of the `Foo` class
 does.  It's not *really* part of `IFoo`.  You wouldn't normally call
 the `__init__` method on Foo instances.  Rather, the `__init__` method
-is part of the `Foo`'s `__call__` method:
+is part of the `Foo`'s `__call__` method::
 
   >>> class IFooFactory(zope.interface.Interface):
   ...     """Create foos"""
@@ -220,11 +220,11 @@
   ...         """
 
 It's the class that provides this interface, so we declare the
-interface on the class:
+interface on the class::
 
   >>> zope.interface.directlyProvides(Foo, IFooFactory)
 
-And then, we'll see that Foo provides some interfaces:
+And then, we'll see that Foo provides some interfaces::
 
   >>> list(zope.interface.providedBy(Foo))
   [<InterfaceClass __main__.IFooFactory>]
@@ -233,7 +233,7 @@
 
 Declaring class interfaces is common enough that there's a special
 declaration function for it, `classProvides`, that allows the
-declaration from within a class statement:
+declaration from within a class statement::
 
   >>> class Foo2:
   ...     zope.interface.implements(IFoo)
@@ -260,7 +260,7 @@
 
 Sometimes, we want to declare interfaces on instances, even though
 those instances get interfaces from their classes.  Suppose we create
-a new interface, `ISpecial`:
+a new interface, `ISpecial`::
 
   >>> class ISpecial(zope.interface.Interface):
   ...     reason = zope.interface.Attribute("Reason why we're special")
@@ -268,7 +268,7 @@
   ...         "Brag about being special"
 
 We can make a an existing foo instance special by providing `reason`
-and `brag` attributes:
+and `brag` attributes::
 
   >>> foo.reason = 'I just am'
   >>> def brag():
@@ -279,18 +279,18 @@
   >>> foo.brag()
   "I'm special!"
 
-and by declaring the interface:
+and by declaring the interface::
 
   >>> zope.interface.directlyProvides(foo, ISpecial)
 
-then the new interface is included in the provided interfaces:
+then the new interface is included in the provided interfaces::
 
   >>> ISpecial.providedBy(foo)
   True
   >>> list(zope.interface.providedBy(foo))
   [<InterfaceClass __main__.ISpecial>, <InterfaceClass __main__.IFoo>]
 
-We can find out what interfaces are directly provided by an object:
+We can find out what interfaces are directly provided by an object::
 
   >>> list(zope.interface.directlyProvidedBy(foo))
   [<InterfaceClass __main__.ISpecial>]
@@ -302,7 +302,7 @@
 Inherited declarations
 ----------------------
 
-Normally, declarations are inherited:
+Normally, declarations are inherited::
 
   >>> class SpecialFoo(Foo):
   ...     zope.interface.implements(ISpecial)
@@ -317,7 +317,7 @@
   [<InterfaceClass __main__.ISpecial>, <InterfaceClass __main__.IFoo>]
 
 Sometimes, you don't want to inherit declarations.  In that case, you
-can use `implementsOnly`, instead of `implements`:
+can use `implementsOnly`, instead of `implements`::
 
   >>> class Special(Foo):
   ...     zope.interface.implementsOnly(ISpecial)
@@ -338,7 +338,7 @@
 definition. Sometimes, we may want to make declarations from outside
 the class definition. For example, we might want to declare interfaces
 for classes that we didn't write.  The function `classImplements` can
-be used for this purpose:
+be used for this purpose::
 
   >>> class C:
   ...     pass
@@ -347,7 +347,7 @@
   >>> list(zope.interface.implementedBy(C))
   [<InterfaceClass __main__.IFoo>]
 
-We can use `classImplementsOnly` to exclude inherited interfaces:
+We can use `classImplementsOnly` to exclude inherited interfaces::
 
   >>> class C(Foo):
   ...     pass
@@ -362,7 +362,7 @@
 -------------------
 
 When we declare interfaces, we create *declaration* objects.  When we
-query declarations, declaration objects are returned:
+query declarations, declaration objects are returned::
 
   >>> type(zope.interface.implementedBy(Special))
   <class 'zope.interface.declarations.Implements'>
@@ -370,7 +370,7 @@
 Declaration objects and interface objects are similar in many ways. In
 fact, they share a common base class.  The important thing to realize
 about them is that they can be used where interfaces are expected in
-declarations. Here's a silly example:
+declarations. Here's a silly example::
 
   >>> class Special2(Foo):
   ...     zope.interface.implementsOnly(
@@ -383,7 +383,7 @@
 
 The declaration here is almost the same as
 ``zope.interface.implements(ISpecial)``, except that the order of
-interfaces in the resulting declaration is different:
+interfaces in the resulting declaration is different::
 
   >>> list(zope.interface.implementedBy(Special2))
   [<InterfaceClass __main__.IFoo>, <InterfaceClass __main__.ISpecial>]
@@ -395,7 +395,7 @@
 =====================
 
 Interfaces can extend other interfaces. They do this simply by listing
-the other interfaces as base interfaces:
+the other interfaces as base interfaces::
 
   >>> class IBlat(zope.interface.Interface):
   ...     """Blat blah blah"""
@@ -421,7 +421,7 @@
   >>> names
   ['bar', 'eek', 'x', 'y']
 
-Note that `IBaz` overrides eek:
+Note that `IBaz` overrides eek::
 
   >>> IBlat['eek'].__doc__
   'eek blah blah'
@@ -432,19 +432,19 @@
 extending an interface, the extending interface should be compatible
 [#compat]_ with the extended interfaces.
 
-We can ask whether one interface extends another:
+We can ask whether one interface extends another::
 
   >>> IBaz.extends(IFoo)
   True
   >>> IBlat.extends(IFoo)
   False
 
-Note that interfaces don't extend themselves:
+Note that interfaces don't extend themselves::
 
   >>> IBaz.extends(IBaz)
   False
 
-Sometimes we wish they did, but we can, instead use `isOrExtends`:
+Sometimes we wish they did, but we can, instead use `isOrExtends`::
 
   >>> IBaz.isOrExtends(IBaz)
   True
@@ -456,7 +456,7 @@
 When we iterate over an interface, we get all of the names it defines,
 including names defined by base interfaces. Sometimes, we want *just*
 the names defined by the interface directly. We bane use the `names`
-method for that:
+method for that::
 
   >>> list(IBaz.names())
   ['eek']
@@ -467,7 +467,7 @@
 
 Interfaces and attribute descriptions support an extension mechanism,
 borrowed from UML, called "tagged values" that lets us store extra
-data:
+data::
 
   >>> IFoo.setTaggedValue('date-modified', '2004-04-01')
   >>> IFoo.setTaggedValue('author', 'Jim Fulton')
@@ -482,7 +482,7 @@
   ['author', 'date-modified']
 
 Function attributes are converted to tagged values when method
-attribute definitions are created:
+attribute definitions are created::
 
   >>> class IBazFactory(zope.interface.Interface):
   ...     def __call__():
@@ -500,7 +500,7 @@
 provide them. These conditions are expressed using one or more
 invariants.  Invariants are callable objects that will be called with
 an object that provides an interface. An invariant raises an `Invalid`
-exception if the condition doesn't hold.  Here's an example:
+exception if the condition doesn't hold.  Here's an example::
 
   >>> class RangeError(zope.interface.Invalid):
   ...     """A range has invalid limits"""
@@ -511,7 +511,7 @@
   ...     if ob.max < ob.min:
   ...         raise RangeError(ob)
 
-Given this invariant, we can use it in an interface definition:
+Given this invariant, we can use it in an interface definition::
 
   >>> class IRange(zope.interface.Interface):
   ...     min = zope.interface.Attribute("Lower bound")
@@ -519,7 +519,7 @@
   ...
   ...     zope.interface.invariant(range_invariant)
 
-Interfaces have a method for checking their invariants:
+Interfaces have a method for checking their invariants::
 
   >>> class Range(object):
   ...     zope.interface.implements(IRange)
@@ -540,7 +540,7 @@
 If you have multiple invariants, you may not want to stop checking
 after the first error.  If you pass a list to `validateInvariants`,
 then a single `Invalid` exception will be raised with the list of
-exceptions as it's argument:
+exceptions as it's argument::
 
   >>> errors = []
   >>> IRange.validateInvariants(Range(2,1), errors)
@@ -548,7 +548,7 @@
   ...
   Invalid: [RangeError(Range(2, 1))]
 
-And the list will be filled with the individual exceptions:
+And the list will be filled with the individual exceptions::
   
   >>> errors
   [RangeError(Range(2, 1))]

Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/adapter.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -94,7 +94,7 @@
   >>> registry.lookup([IR1], IP1, 'bob')
   "Bob's 12"
 
-You can leave the name off when doing a lookup:
+You can leave the name off when doing a lookup::
 
   >>> registry.lookup([IR1], IP1)
   12
@@ -118,8 +118,8 @@
 lookup1
 -------
 
-Lookup of single adapters is common enough that there is a
-specialized version of lookup that takes a single required interface:
+Lookup of single adapters is common enough that there is a specialized
+version of lookup that takes a single required interface::
 
   >>> registry.lookup1(IR2, IP1, '')
   21
@@ -133,7 +133,7 @@
 object that implements an interface is adapted to another object that
 supports a different interface.  The adapter registry supports the
 computation of adapters. In this case, we have to register adapter
-factories: 
+factories::
 
    >>> class IR(zope.interface.Interface):
    ...     pass
@@ -149,7 +149,7 @@
   >>> registry.register([IR], IP1, '', Y)
 
 In this case, we registered a class as the factory. Now we can call
-`queryAdapter` to get the adapted object:
+`queryAdapter` to get the adapted object::
 
   >>> x = X()
   >>> y = registry.queryAdapter(x, IP1)
@@ -158,7 +158,7 @@
   >>> y.context is x
   True
 
-We can register and lookup by name too:
+We can register and lookup by name too::
 
   >>> class Y2(Y):
   ...     pass
@@ -170,8 +170,8 @@
   >>> y.context is x
   True
 
-An alternate method that provides the same function as `queryAdapter` is
-`adapter_hook`:
+An alternate method that provides the same function as `queryAdapter()` is
+`adapter_hook()`::
 
   >>> y = registry.adapter_hook(IP1, x)
   >>> y.__class__.__name__
@@ -184,7 +184,7 @@
   >>> y.context is x
   True
 
-The `adapter_hook` simply switches the order of the object and
+The `adapter_hook()` simply switches the order of the object and
 interface arguments.  It is used to hook into the interface call
 mechanism.
 
@@ -223,7 +223,7 @@
 Unregistering
 -------------
 
-You can unregister by registering None, rather than an object:;
+You can unregister by registering None, rather than an object::
 
   >>> registry.register([zope.interface.implementedBy(C2)], IP1, '', None)
   >>> registry.lookup([zope.interface.implementedBy(C2)], IP1, '')
@@ -261,12 +261,12 @@
 Multi-adaptation
 ----------------
 
-You can adapt multiple objects:
+You can adapt multiple objects::
 
   >>> class Q:
   ...     zope.interface.implements(IQ)
 
-As with single adapters, we register a factory, which is often a class:
+As with single adapters, we register a factory, which is often a class::
 
   >>> class IM(zope.interface.Interface):
   ...     pass
@@ -276,7 +276,7 @@
   ...         self.x, self.q = x, q
   >>> registry.register([IR, IQ], IM, '', M)
 
-And then we can call `queryMultiAdapter` to compute an adapter:
+And then we can call `queryMultiAdapter` to compute an adapter::
 
   >>> q = Q()
   >>> m = registry.queryMultiAdapter((x, q), IM)
@@ -285,7 +285,7 @@
   >>> m.x is x and m.q is q
   True
 
-and, of course, we can use names:
+and, of course, we can use names::
 
   >>> class M2(M):
   ...     pass
@@ -300,7 +300,7 @@
 ----------------
 
 As with single adapters, you can define default adapters by specifying
-None for the *first* specification:
+None for the *first* specification::
 
   >>> registry.register([None, IQ], IP2, '', 'q2')
   >>> registry.lookup([IS, IQ], IP2, '')
@@ -309,7 +309,7 @@
 Null Adapters
 =============
 
-You can also adapt no specification:
+You can also adapt no specification::
 
   >>> registry.register([], IP2, '', 2)
   >>> registry.lookup([], IP2, '')
@@ -321,14 +321,14 @@
 ----------------------
 
 Adapters are named. Sometimes, it's useful to get all of the named
-adapters for given interfaces.
+adapters for given interfaces::
 
   >>> adapters = list(registry.lookupAll([IR1], IP1))
   >>> adapters.sort()
   >>> adapters
   [(u'', 11), (u'bob', "Bob's 12")]
 
-This works for multi-adapters too:
+This works for multi-adapters too::
 
   >>> registry.register([IR1, IQ2], IP2, 'bob', '1q2 for bob')
   >>> adapters = list(registry.lookupAll([IR2, IQ2], IP1))
@@ -336,7 +336,7 @@
   >>> adapters
   [(u'', '1q22'), (u'bob', '1q2 for bob')]
 
-And even null adapters:
+And even null adapters::
 
   >>> registry.register([], IP2, 'bob', 3)
   >>> adapters = list(registry.lookupAll([], IP1))
@@ -437,7 +437,7 @@
 
 We normally register adapter factories, which then allow us to compute
 adapters, but with subscriptions, we get multiple adapters.  Here's an
-example of multiple-object subscribers:
+example of multiple-object subscribers::
 
   >>> registry.subscribe([IR, IQ], IM, M)
   >>> registry.subscribe([IR, IQ], IM, M2)
@@ -460,7 +460,7 @@
 output.  It returns None.  A handler is unlike adapters in that it does
 all of it's work when the factory is called.
 
-To register a handler, simply provide None as the provided interface:
+To register a handler, simply provide None as the provided interface::
 
   >>> def handler(event):
   ...     print 'handler', event

Modified: Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/interface/tests/foodforthought.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -3,7 +3,7 @@
 ================================
 
 
-This file gives more subscription examples using a cooking-based examples
+This file gives more subscription examples using a cooking-based example::
 
     >>> from zope.interface.adapter import AdapterRegistry
     >>> registry = AdapterRegistry()
@@ -19,7 +19,7 @@
     ...     pass
 
 Adapting to some other interface for which there is no
-subscription adapter returns an empty sequence:
+subscription adapter returns an empty sequence::
 
     >>> class IRecipe(zope.interface.Interface):
     ...     pass
@@ -30,32 +30,32 @@
     >>> class IKFC(IRecipe):
     ...     pass
 
->>> list(registry.subscriptions([IPoultry], IRecipe))
-[]
+    >>> list(registry.subscriptions([IPoultry], IRecipe))
+    []
 
 unless we define a subscription::
 
->>> registry.subscribe([IAnimal], ISausages, 'sausages')
->>> list(registry.subscriptions([IPoultry], ISausages))
-['sausages']
+    >>> registry.subscribe([IAnimal], ISausages, 'sausages')
+    >>> list(registry.subscriptions([IPoultry], ISausages))
+    ['sausages']
 
-And define another subscription adapter:
+And define another subscription adapter::
 
->>> registry.subscribe([IPoultry], INoodles, 'noodles')
->>> meals = list(registry.subscriptions([IPoultry], IRecipe))
->>> meals.sort()
->>> meals
-['noodles', 'sausages']
+    >>> registry.subscribe([IPoultry], INoodles, 'noodles')
+    >>> meals = list(registry.subscriptions([IPoultry], IRecipe))
+    >>> meals.sort()
+    >>> meals
+    ['noodles', 'sausages']
 
->>> registry.subscribe([IChicken], IKFC, 'kfc')
->>> meals = list(registry.subscriptions([IChicken], IRecipe))
->>> meals.sort()
->>> meals
-['kfc', 'noodles', 'sausages']
+    >>> registry.subscribe([IChicken], IKFC, 'kfc')
+    >>> meals = list(registry.subscriptions([IChicken], IRecipe))
+    >>> meals.sort()
+    >>> meals
+    ['kfc', 'noodles', 'sausages']
 
-And the answer for poultry hasn't changed:
+And the answer for poultry hasn't changed::
 
->>> meals = list(registry.subscriptions([IPoultry], IRecipe))
->>> meals.sort()
->>> meals
-['noodles', 'sausages']
+    >>> meals = list(registry.subscriptions([IPoultry], IRecipe))
+    >>> meals.sort()
+    >>> meals
+    ['noodles', 'sausages']

Modified: Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt	2004-07-16 19:01:59 UTC (rev 26588)
+++ Zope3/branches/ZopeX3-3.0/src/zope/schema/fields.txt	2004-07-16 19:28:56 UTC (rev 26589)
@@ -152,4 +152,4 @@
 on the basis of uniqueness and other constraints.
 
 This level of indirection may be unnecessary for some applications, and can be
-disabled with simple zcml changes within zope.app.
+disabled with simple ZCML changes within `zope.app`.



More information about the Zope3-Checkins mailing list