Commit ad8303c6 authored by Ramiro Batista da Luz's avatar Ramiro Batista da Luz Committed by Michael Howitz

Fix some typos in docs. (#103)

parent ed81c6f7
......@@ -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::
......
......@@ -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:
......
......@@ -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::
......
......@@ -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`.
......
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment