Fix some typos in docs. (#103)

docs/api/attributes.rst

@@ -109,7 +109,7 @@ which activates the object:
    >>> o._p_changed
    False
 
-It works for missing attribes too:
+It works for missing attributes too:
 
 .. doctest::
 
@@ -182,7 +182,7 @@ We'll modify an attribute
    >>> o.y
    2
 
-which reactivates it, and markes it as modified, because our
+which reactivates it, and marks it as modified, because our
 implementation marked it as modified:
 
 .. doctest::

docs/api/cache.rst

@@ -20,14 +20,14 @@ really provide the right interface given that:
    The current cache implementation is intimately tied up with the
    persistence implementation and has internal access to the persistence
    state.  The cache implementation can update the persistence state for
-   newly created and ininitialized objects directly.
+   newly created and uninitialized objects directly.
 
    The future persistence and cache implementations will be far more
    decoupled. The persistence implementation will only manage object
-   state and generate object-usage events.  The cache implemnentation(s)
-   will be rersponsible for managing persistence-related (meta-)state,
+   state and generate object-usage events.  The cache implementation(s)
+   will be responsible for managing persistence-related (meta-)state,
    such as _p_state, _p_changed, _p_oid, etc.  So in that future
-   implemention, the cache will be more central to managing object
+   implementation, the cache will be more central to managing object
    persistence information.
 
 Caches have a :meth:`new_ghost` method that:

docs/api/pickling.rst

@@ -82,7 +82,7 @@ ignores any slots which map onto the "persistent" namespace (prefixed with
    >>> from persistent.tests.cucumbers import SubSlotted
    >>> x = SubSlotted('x', 'y', 'z')
 
-Note that we haven't yet assiged a value to the ``s4`` attribute:
+Note that we haven't yet assigned a value to the ``s4`` attribute:
 
 .. doctest::
 

docs/glossary.rst

@@ -23,7 +23,7 @@ Glossary
      that data to be loaded, which is referred to as :term:`activation`.
 
    volatile attribute
-     Attributes of a persistent object which are *not* caputured as part
+     Attributes of a persistent object which are *not* captured as part
      of its :term:`pickled data`.  These attributes thus disappear during
      :term:`deactivation` or :term:`invalidation`.
 

docs/using.rst

@@ -7,7 +7,7 @@ Inheriting from :class:`persistent.Persistent`
 ==============================================
 
 The basic mechanism for making your application's objects persistent
-is mix-in interitance.  Instances whose classes derive from
+is mix-in inheritance.  Instances whose classes derive from
 :class:`persistent.Persistent` are automatically capable of being
 created as :term:`ghost` instances, being associated with a database
 connection (called the :term:`jar`), and notifying the connection when
@@ -59,14 +59,14 @@ The examples below use a stub data manager class, and its stub cache class:
    ...         ob.__setstate__({'x': 42})
 
 .. note::
-   Notic that the ``DM`` class always sets the ``x`` attribute to the value
+   Notice that the ``DM`` class always sets the ``x`` attribute to the value
    ``42`` when activating an object.
 
 
 Persistent objects without a Data Manager
 =========================================
 
-Before aersistent instance has been associtated with a a data manager (
+Before persistent instance has been associated with a a data manager (
 i.e., its ``_p_jar`` is still ``None``).
 
 The examples below use a class, ``P``, defined as:
@@ -102,7 +102,7 @@ will always be ``False``.
    >>> p._p_changed
    False
 
-The :attr:`_p_state` attribute is an integaer, representing which of the
+The :attr:`_p_state` attribute is an integer, representing which of the
 "persistent lifecycle" states the object is in.  Until the object is assigned
 a :term:`jar`, this attribute will always be ``0`` (the ``UPTODATE``
 constant):
@@ -437,9 +437,9 @@ Subclasses which override the attribute-management methods provided by
   derived implementation must assume that the attribute value has been set by
   the base class.
 
-:meth:`__detattr__`
-  When overriding ``__detattr__``, the derived class implementation
-  **must** first call :meth:`persistent.IPersistent._p_detattr`, passing the
+:meth:`__delattr__`
+  When overriding ``__delattr__``, the derived class implementation
+  **must** first call :meth:`persistent.IPersistent._p_delattr`, passing the
   name being accessed.  This method ensures that the object is
   activated, if needed, and handles the "special" attributes which do not
   require activation (``_p_*``).  If ``_p_delattr`` returns ``True``, the