Small docs style fixes in inheritance.rst

Change-Id: I01d217cf1a8a1a8791e3b44167dfc4d6a0c77cdb
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/445

diff --git a/doc/build/orm/inheritance.rst b/doc/build/orm/inheritance.rst
index 794fc391c42a557f3cd26a886a2ed01e8702c555..553fb929111b0d18a2792cf2ed96c7fb5853acec 100644 (file)
--- a/doc/build/orm/inheritance.rst
+++ b/doc/build/orm/inheritance.rst
@@ -30,14 +30,15 @@ Joined Table Inheritance
 In joined table inheritance, each class along a hierarchy of classes
 is represented by a distinct table.  Querying for a particular subclass
 in the hierarchy will render as a SQL JOIN along all tables in its
-inheritance path - if the class is the base class, the default behavior
-is to include only the base table in the SELECT.   In all cases, the
+inheritance path. If the queried class is the base class, the **default behavior
+is to include only the base table** in a SELECT statement.   In all cases, the
 ultimate class to instantiate for a given row is determined by a discriminator
-column or expression that works against the base table.    A subclass
-loaded against the base table only will have only base attributes
-populated at first; the additional attributes will :term:`lazy load` when
-they are accessed.  Options also exist to query for all
-columns across multiple tables/subclasses up front.
+column or an expression that works against the base table.    When a subclass
+is loaded **only** against a base table, resulting objects will have base attributes
+populated at first; attributes that are local to the subclass will :term:`lazy load`
+when they are accessed.    Alternatively, there are options which can change
+the default behavior, allowing the query to include columns corresponding to
+multiple tables/subclasses up front.
 
 The base class in a joined inheritance hierarchy is configured with
 additional arguments that will refer to the polymorphic discriminator