Run search and replace of symbolic module names

Replaces a wide array of Sphinx-relative doc references
with an abbreviated absolute form now supported by
zzzeeksphinx.

Change-Id: I94bffcc3f37885ffdde6238767224296339698a2

11 files changed, 151 insertions, 115 deletions

diff --git a/lib/sqlalchemy/ext/associationproxy.py b/lib/sqlalchemy/ext/associationproxy.py
index 599bf966d..fc10cb88d 100644
--- a/lib/sqlalchemy/ext/associationproxy.py
+++ b/lib/sqlalchemy/ext/associationproxy.py
@@ -114,7 +114,7 @@ class AssociationProxy(interfaces.InspectionAttrInfo):
         and/or subclassed directly.
 
         :param target_collection: Name of the collection we'll proxy to,
-          usually created with :func:`.relationship`.
+          usually created with :func:`_orm.relationship`.
 
         :param attr: Attribute on the collected instances we'll proxy
           for.  For example, given a target collection of [obj1, obj2], a
@@ -216,7 +216,7 @@ class AssociationProxy(interfaces.InspectionAttrInfo):
                 keywords = association_proxy('kws', 'keyword')
 
         If we access this :class:`.AssociationProxy` from
-        :attr:`.Mapper.all_orm_descriptors`, and we want to view the
+        :attr:`_orm.Mapper.all_orm_descriptors`, and we want to view the
         target class for this proxy as mapped by ``User``::
 
             inspect(User).all_orm_descriptors["keywords"].for_class(User).target_class
@@ -467,7 +467,7 @@ class AssociationProxyInstance(object):
         """Return a tuple of ``(local_attr, remote_attr)``.
 
         This attribute is convenient when specifying a join
-        using :meth:`.Query.join` across two relationships::
+        using :meth:`_query.Query.join` across two relationships::
 
             sess.query(Parent).join(*Parent.proxied.attr)
 
diff --git a/lib/sqlalchemy/ext/automap.py b/lib/sqlalchemy/ext/automap.py
index e409cf38c..4ae3a415e 100644
--- a/lib/sqlalchemy/ext/automap.py
+++ b/lib/sqlalchemy/ext/automap.py
@@ -60,12 +60,16 @@ asking it to reflect the schema and produce mappings::
 
 Above, calling :meth:`.AutomapBase.prepare` while passing along the
 :paramref:`.AutomapBase.prepare.reflect` parameter indicates that the
-:meth:`.MetaData.reflect` method will be called on this declarative base
-classes' :class:`.MetaData` collection; then, each **viable**
-:class:`.Table` within the :class:`.MetaData` will get a new mapped class
-generated automatically.  The :class:`.ForeignKeyConstraint` objects which
+:meth:`_schema.MetaData.reflect`
+method will be called on this declarative base
+classes' :class:`_schema.MetaData` collection; then, each **viable**
+:class:`_schema.Table` within the :class:`_schema.MetaData`
+will get a new mapped class
+generated automatically.  The :class:`_schema.ForeignKeyConstraint`
+objects which
 link the various tables together will be used to produce new, bidirectional
-:func:`.relationship` objects between classes.   The classes and relationships
+:func:`_orm.relationship` objects between classes.
+The classes and relationships
 follow along a default naming scheme that we can customize.  At this point,
 our basic mapping consisting of related ``User`` and ``Address`` classes is
 ready to use in the traditional way.
@@ -79,10 +83,12 @@ ready to use in the traditional way.
 Generating Mappings from an Existing MetaData
 =============================================
 
-We can pass a pre-declared :class:`.MetaData` object to :func:`.automap_base`.
+We can pass a pre-declared :class:`_schema.MetaData` object to
+:func:`.automap_base`.
 This object can be constructed in any way, including programmatically, from
 a serialized file, or from itself being reflected using
-:meth:`.MetaData.reflect`.  Below we illustrate a combination of reflection and
+:meth:`_schema.MetaData.reflect`.
+Below we illustrate a combination of reflection and
 explicit table declaration::
 
     from sqlalchemy import create_engine, MetaData, Table, Column, ForeignKey
@@ -160,7 +166,7 @@ established based on the table name we use.  If our schema contains tables
     print (a1.user)
 
 Above, one of the more intricate details is that we illustrated overriding
-one of the :func:`.relationship` objects that automap would have created.
+one of the :func:`_orm.relationship` objects that automap would have created.
 To do this, we needed to make sure the names match up with what automap
 would normally generate, in that the relationship name would be
 ``User.address_collection`` and the name of the class referred to, from
@@ -226,39 +232,43 @@ Relationship Detection
 ======================
 
 The vast majority of what automap accomplishes is the generation of
-:func:`.relationship` structures based on foreign keys.  The mechanism
+:func:`_orm.relationship` structures based on foreign keys.  The mechanism
 by which this works for many-to-one and one-to-many relationships is as
 follows:
 
-1. A given :class:`.Table`, known to be mapped to a particular class,
-   is examined for :class:`.ForeignKeyConstraint` objects.
+1. A given :class:`_schema.Table`, known to be mapped to a particular class,
+   is examined for :class:`_schema.ForeignKeyConstraint` objects.
 
-2. From each :class:`.ForeignKeyConstraint`, the remote :class:`.Table`
+2. From each :class:`_schema.ForeignKeyConstraint`, the remote
+   :class:`_schema.Table`
    object present is matched up to the class to which it is to be mapped,
    if any, else it is skipped.
 
-3. As the :class:`.ForeignKeyConstraint` we are examining corresponds to a
+3. As the :class:`_schema.ForeignKeyConstraint`
+   we are examining corresponds to a
    reference from the immediate mapped class,  the relationship will be set up
    as a many-to-one referring to the referred class; a corresponding
    one-to-many backref will be created on the referred class referring
    to this class.
 
-4. If any of the columns that are part of the :class:`.ForeignKeyConstraint`
+4. If any of the columns that are part of the
+   :class:`_schema.ForeignKeyConstraint`
    are not nullable (e.g. ``nullable=False``), a
-   :paramref:`~.relationship.cascade` keyword argument
+   :paramref:`_orm.relationship.cascade` keyword argument
    of ``all, delete-orphan`` will be added to the keyword arguments to
    be passed to the relationship or backref.  If the
-   :class:`.ForeignKeyConstraint` reports that
-   :paramref:`.ForeignKeyConstraint.ondelete`
+   :class:`_schema.ForeignKeyConstraint` reports that
+   :paramref:`_schema.ForeignKeyConstraint.ondelete`
    is set to ``CASCADE`` for a not null or ``SET NULL`` for a nullable
-   set of columns, the option :paramref:`~.relationship.passive_deletes`
+   set of columns, the option :paramref:`_orm.relationship.passive_deletes`
    flag is set to ``True`` in the set of relationship keyword arguments.
    Note that not all backends support reflection of ON DELETE.
 
    .. versionadded:: 1.0.0 - automap will detect non-nullable foreign key
       constraints when producing a one-to-many relationship and establish
       a default cascade of ``all, delete-orphan`` if so; additionally,
-      if the constraint specifies :paramref:`.ForeignKeyConstraint.ondelete`
+      if the constraint specifies
+      :paramref:`_schema.ForeignKeyConstraint.ondelete`
       of ``CASCADE`` for non-nullable or ``SET NULL`` for nullable columns,
       the ``passive_deletes=True`` option is also added.
 
@@ -274,18 +284,20 @@ follows:
 6. The classes are inspected for an existing mapped property matching these
    names.  If one is detected on one side, but none on the other side,
    :class:`.AutomapBase` attempts to create a relationship on the missing side,
-   then uses the :paramref:`.relationship.back_populates` parameter in order to
+   then uses the :paramref:`_orm.relationship.back_populates`
+   parameter in order to
    point the new relationship to the other side.
 
 7. In the usual case where no relationship is on either side,
-   :meth:`.AutomapBase.prepare` produces a :func:`.relationship` on the
+   :meth:`.AutomapBase.prepare` produces a :func:`_orm.relationship` on the
    "many-to-one" side and matches it to the other using the
-   :paramref:`.relationship.backref` parameter.
+   :paramref:`_orm.relationship.backref` parameter.
 
-8. Production of the :func:`.relationship` and optionally the :func:`.backref`
+8. Production of the :func:`_orm.relationship` and optionally the
+   :func:`.backref`
    is handed off to the :paramref:`.AutomapBase.prepare.generate_relationship`
    function, which can be supplied by the end-user in order to augment
-   the arguments passed to :func:`.relationship` or :func:`.backref` or to
+   the arguments passed to :func:`_orm.relationship` or :func:`.backref` or to
    make use of custom implementations of these functions.
 
 Custom Relationship Arguments
@@ -298,8 +310,8 @@ the object, after augmenting the given keyword dictionary with our own
 arguments.
 
 Below is an illustration of how to send
-:paramref:`.relationship.cascade` and
-:paramref:`.relationship.passive_deletes`
+:paramref:`_orm.relationship.cascade` and
+:paramref:`_orm.relationship.passive_deletes`
 options along to all one-to-many relationships::
 
     from sqlalchemy.ext.automap import generate_relationship
@@ -331,20 +343,24 @@ Many-to-Many relationships
 those which contain a ``secondary`` argument.  The process for producing these
 is as follows:
 
-1. A given :class:`.Table` is examined for :class:`.ForeignKeyConstraint`
+1. A given :class:`_schema.Table` is examined for
+   :class:`_schema.ForeignKeyConstraint`
    objects, before any mapped class has been assigned to it.
 
-2. If the table contains two and exactly two :class:`.ForeignKeyConstraint`
+2. If the table contains two and exactly two
+   :class:`_schema.ForeignKeyConstraint`
    objects, and all columns within this table are members of these two
-   :class:`.ForeignKeyConstraint` objects, the table is assumed to be a
+   :class:`_schema.ForeignKeyConstraint` objects, the table is assumed to be a
    "secondary" table, and will **not be mapped directly**.
 
 3. The two (or one, for self-referential) external tables to which the
-   :class:`.Table` refers to are matched to the classes to which they will be
+   :class:`_schema.Table`
+   refers to are matched to the classes to which they will be
    mapped, if any.
 
 4. If mapped classes for both sides are located, a many-to-many bi-directional
-   :func:`.relationship` / :func:`.backref` pair is created between the two
+   :func:`_orm.relationship` / :func:`.backref`
+   pair is created between the two
    classes.
 
 5. The override logic for many-to-many works the same as that of one-to-many/
@@ -469,7 +485,8 @@ Using Automap with Explicit Declarations
 ========================================
 
 As noted previously, automap has no dependency on reflection, and can make
-use of any collection of :class:`.Table` objects within a :class:`.MetaData`
+use of any collection of :class:`_schema.Table` objects within a
+:class:`_schema.MetaData`
 collection.  From this, it follows that automap can also be used
 generate missing relationships given an otherwise complete model that fully
 defines table metadata::
@@ -503,7 +520,7 @@ defines table metadata::
     assert a1.user is u1
 
 Above, given mostly complete ``User`` and ``Address`` mappings, the
-:class:`.ForeignKey` which we defined on ``Address.user_id`` allowed a
+:class:`_schema.ForeignKey` which we defined on ``Address.user_id`` allowed a
 bidirectional relationship pair ``Address.user`` and
 ``User.address_collection`` to be generated on the mapped classes.
 
@@ -539,9 +556,9 @@ def classname_for_table(base, tablename, table):
 
     :param base: the :class:`.AutomapBase` class doing the prepare.
 
-    :param tablename: string name of the :class:`.Table`.
+    :param tablename: string name of the :class:`_schema.Table`.
 
-    :param table: the :class:`.Table` object itself.
+    :param table: the :class:`_schema.Table` object itself.
 
     :return: a string class name.
 
@@ -549,7 +566,8 @@ def classname_for_table(base, tablename, table):
 
         In Python 2, the string used for the class name **must** be a
         non-Unicode object, e.g. a ``str()`` object.  The ``.name`` attribute
-        of :class:`.Table` is typically a Python unicode subclass, so the
+        of :class:`_schema.Table` is typically a Python unicode subclass,
+        so the
         ``str()`` function should be applied to this name, after accounting for
         any non-ASCII characters.
 
@@ -575,7 +593,7 @@ def name_for_scalar_relationship(base, local_cls, referred_cls, constraint):
 
     :param referred_cls: the class to be mapped on the referring side.
 
-    :param constraint: the :class:`.ForeignKeyConstraint` that is being
+    :param constraint: the :class:`_schema.ForeignKeyConstraint` that is being
      inspected to produce this relationship.
 
     """
@@ -603,7 +621,7 @@ def name_for_collection_relationship(
 
     :param referred_cls: the class to be mapped on the referring side.
 
-    :param constraint: the :class:`.ForeignKeyConstraint` that is being
+    :param constraint: the :class:`_schema.ForeignKeyConstraint` that is being
      inspected to produce this relationship.
 
     """
@@ -613,7 +631,8 @@ def name_for_collection_relationship(
 def generate_relationship(
     base, direction, return_fn, attrname, local_cls, referred_cls, **kw
 ):
-    r"""Generate a :func:`.relationship` or :func:`.backref` on behalf of two
+    r"""Generate a :func:`_orm.relationship` or :func:`.backref`
+    on behalf of two
     mapped classes.
 
     An alternate implementation of this function can be specified using the
@@ -634,9 +653,10 @@ def generate_relationship(
      be one of :data:`.ONETOMANY`, :data:`.MANYTOONE`, :data:`.MANYTOMANY`.
 
     :param return_fn: the function that is used by default to create the
-     relationship.  This will be either :func:`.relationship` or
+     relationship.  This will be either :func:`_orm.relationship` or
      :func:`.backref`.  The :func:`.backref` function's result will be used to
-     produce a new :func:`.relationship` in a second step, so it is critical
+     produce a new :func:`_orm.relationship` in a second step,
+     so it is critical
      that user-defined implementations correctly differentiate between the two
      functions, if a custom relationship function is being used.
 
@@ -654,7 +674,8 @@ def generate_relationship(
     :param \**kw: all additional keyword arguments are passed along to the
      function.
 
-    :return: a :func:`.relationship` or :func:`.backref` construct, as dictated
+    :return: a :func:`_orm.relationship` or :func:`.backref` construct,
+     as dictated
      by the :paramref:`.generate_relationship.return_fn` parameter.
 
     """
@@ -710,19 +731,24 @@ class AutomapBase(object):
         name_for_collection_relationship=name_for_collection_relationship,
         generate_relationship=generate_relationship,
     ):
-        """Extract mapped classes and relationships from the :class:`.MetaData` and
+        """Extract mapped classes and relationships from the
+        :class:`_schema.MetaData` and
         perform mappings.
 
-        :param engine: an :class:`.Engine` or :class:`.Connection` with which
+        :param engine: an :class:`_engine.Engine` or
+         :class:`_engine.Connection` with which
          to perform schema reflection, if specified.
          If the :paramref:`.AutomapBase.prepare.reflect` argument is False,
          this object is not used.
 
-        :param reflect: if True, the :meth:`.MetaData.reflect` method is called
-         on the :class:`.MetaData` associated with this :class:`.AutomapBase`.
-         The :class:`.Engine` passed via
+        :param reflect: if True, the :meth:`_schema.MetaData.reflect`
+         method is called
+         on the :class:`_schema.MetaData` associated with this
+         :class:`.AutomapBase`.
+         The :class:`_engine.Engine` passed via
          :paramref:`.AutomapBase.prepare.engine` will be used to perform the
-         reflection if present; else, the :class:`.MetaData` should already be
+         reflection if present; else, the :class:`_schema.MetaData`
+         should already be
          bound to some engine else the operation will fail.
 
         :param classname_for_table: callable function which will be used to
@@ -738,16 +764,18 @@ class AutomapBase(object):
          relationships.  Defaults to :func:`.name_for_collection_relationship`.
 
         :param generate_relationship: callable function which will be used to
-         actually generate :func:`.relationship` and :func:`.backref`
+         actually generate :func:`_orm.relationship` and :func:`.backref`
          constructs.  Defaults to :func:`.generate_relationship`.
 
         :param collection_class: the Python collection class that will be used
-         when a new :func:`.relationship` object is created that represents a
+         when a new :func:`_orm.relationship`
+         object is created that represents a
          collection.  Defaults to ``list``.
 
         :param schema: When present in conjunction with the
          :paramref:`.AutomapBase.prepare.reflect` flag, is passed to
-         :meth:`.MetaData.reflect` to indicate the primary schema where tables
+         :meth:`_schema.MetaData.reflect`
+         to indicate the primary schema where tables
          should be reflected from.  When omitted, the default schema in use
          by the database connection is used.
 
diff --git a/lib/sqlalchemy/ext/baked.py b/lib/sqlalchemy/ext/baked.py
index ff741db32..839aae730 100644
--- a/lib/sqlalchemy/ext/baked.py
+++ b/lib/sqlalchemy/ext/baked.py
@@ -147,7 +147,7 @@ class BakedQuery(object):
          :class:`.BakedQuery` object subsequent to the spoil step will be
          non-cached; the state of the :class:`.BakedQuery` up until
          this point will be pulled from the cache.   If True, then the
-         entire :class:`.Query` object is built from scratch each
+         entire :class:`_query.Query` object is built from scratch each
          time, with all creational functions being called on each
          invocation.
 
@@ -165,8 +165,8 @@ class BakedQuery(object):
         :class:`.Session`.
 
         This basically means we also will include the session's query_class,
-        as the actual :class:`.Query` object is part of what's cached
-        and needs to match the type of :class:`.Query` that a later
+        as the actual :class:`_query.Query` object is part of what's cached
+        and needs to match the type of :class:`_query.Query` that a later
         session will want to use.
 
         """
@@ -255,11 +255,11 @@ class BakedQuery(object):
         return context
 
     def to_query(self, query_or_session):
-        """Return the :class:`.Query` object for use as a subquery.
+        """Return the :class:`_query.Query` object for use as a subquery.
 
         This method should be used within the lambda callable being used
         to generate a step of an enclosing :class:`.BakedQuery`.   The
-        parameter should normally be the :class:`.Query` object that
+        parameter should normally be the :class:`_query.Query` object that
         is passed to the lambda::
 
             sub_bq = self.bakery(lambda s: s.query(User.name))
@@ -282,7 +282,7 @@ class BakedQuery(object):
                 Address.id, sub_bq.to_query(q).scalar_subquery())
             )
 
-        :param query_or_session: a :class:`.Query` object or a class
+        :param query_or_session: a :class:`_query.Query` object or a class
          :class:`.Session` object, that is assumed to be within the context
          of an enclosing :class:`.BakedQuery` callable.
 
@@ -394,13 +394,14 @@ class Result(object):
         """Add a criteria function that will be applied post-cache.
 
         This adds a function that will be run against the
-        :class:`.Query` object after it is retrieved from the
+        :class:`_query.Query` object after it is retrieved from the
         cache.    Functions here can be used to alter the query in ways
         that **do not affect the SQL output**, such as execution options
         and shard identifiers (when using a shard-enabled query object)
 
         .. warning::  :meth:`.Result.with_post_criteria` functions are applied
-           to the :class:`.Query` object **after** the query's SQL statement
+           to the :class:`_query.Query`
+           object **after** the query's SQL statement
            object has been retrieved from the cache.   Any operations here
            which intend to modify the SQL should ensure that
            :meth:`.BakedQuery.spoil` was called first.
@@ -449,7 +450,7 @@ class Result(object):
     def count(self):
         """return the 'count'.
 
-        Equivalent to :meth:`.Query.count`.
+        Equivalent to :meth:`_query.Query.count`.
 
         Note this uses a subquery to ensure an accurate count regardless
         of the structure of the original statement.
@@ -467,7 +468,7 @@ class Result(object):
         if no rows present.  If multiple rows are returned,
         raises MultipleResultsFound.
 
-        Equivalent to :meth:`.Query.scalar`.
+        Equivalent to :meth:`_query.Query.scalar`.
 
         .. versionadded:: 1.1.6
 
@@ -483,7 +484,7 @@ class Result(object):
     def first(self):
         """Return the first row.
 
-        Equivalent to :meth:`.Query.first`.
+        Equivalent to :meth:`_query.Query.first`.
 
         """
         bq = self.bq.with_criteria(lambda q: q.slice(0, 1))
@@ -500,7 +501,7 @@ class Result(object):
     def one(self):
         """Return exactly one result or raise an exception.
 
-        Equivalent to :meth:`.Query.one`.
+        Equivalent to :meth:`_query.Query.one`.
 
         """
         try:
@@ -521,7 +522,7 @@ class Result(object):
         """Return one or zero results, or raise an exception for multiple
         rows.
 
-        Equivalent to :meth:`.Query.one_or_none`.
+        Equivalent to :meth:`_query.Query.one_or_none`.
 
         .. versionadded:: 1.0.9
 
@@ -541,7 +542,7 @@ class Result(object):
     def all(self):
         """Return all rows.
 
-        Equivalent to :meth:`.Query.all`.
+        Equivalent to :meth:`_query.Query.all`.
 
         """
         return list(self)
@@ -549,7 +550,7 @@ class Result(object):
     def get(self, ident):
         """Retrieve an object based on identity.
 
-        Equivalent to :meth:`.Query.get`.
+        Equivalent to :meth:`_query.Query.get`.
 
         """
 
@@ -646,7 +647,7 @@ def unbake_lazy_loaders():
 
     This method now raises NotImplementedError() as the "baked" implementation
     is the only lazy load implementation.  The
-    :paramref:`.relationship.bake_queries` flag may be used to disable
+    :paramref:`_orm.relationship.bake_queries` flag may be used to disable
     the caching of queries on a per-relationship basis.
 
     """
diff --git a/lib/sqlalchemy/ext/compiler.py b/lib/sqlalchemy/ext/compiler.py
index b8b6f8dc0..32975a949 100644
--- a/lib/sqlalchemy/ext/compiler.py
+++ b/lib/sqlalchemy/ext/compiler.py
@@ -101,7 +101,7 @@ Produces::
 
     The above ``InsertFromSelect`` construct is only an example, this actual
     functionality is already available using the
-    :meth:`.Insert.from_select` method.
+    :meth:`_expression.Insert.from_select` method.
 
 .. note::
 
@@ -140,7 +140,8 @@ supported.
 Enabling Autocommit on a Construct
 ==================================
 
-Recall from the section :ref:`autocommit` that the :class:`.Engine`, when
+Recall from the section :ref:`autocommit` that the :class:`_engine.Engine`,
+when
 asked to execute a construct in the absence of a user-defined transaction,
 detects if the given construct represents DML or DDL, that is, a data
 modification or data definition statement, which requires (or may require,
@@ -165,7 +166,7 @@ is a "frozen" dictionary which supplies a generative ``union()`` method)::
 
 More succinctly, if the construct is truly similar to an INSERT, UPDATE, or
 DELETE, :class:`.UpdateBase` can be used, which already is a subclass
-of :class:`.Executable`, :class:`.ClauseElement` and includes the
+of :class:`.Executable`, :class:`_expression.ClauseElement` and includes the
 ``autocommit`` flag::
 
     from sqlalchemy.sql.expression import UpdateBase
@@ -405,7 +406,7 @@ from ..sql import visitors
 
 def compiles(class_, *specs):
     """Register a function as a compiler for a
-    given :class:`.ClauseElement` type."""
+    given :class:`_expression.ClauseElement` type."""
 
     def decorate(fn):
         # get an existing @compiles handler
@@ -455,7 +456,7 @@ def compiles(class_, *specs):
 
 def deregister(class_):
     """Remove all custom compilers associated with a given
-    :class:`.ClauseElement` type."""
+    :class:`_expression.ClauseElement` type."""
 
     if hasattr(class_, "_compiler_dispatcher"):
         # regenerate default _compiler_dispatch
diff --git a/lib/sqlalchemy/ext/declarative/api.py b/lib/sqlalchemy/ext/declarative/api.py
index 825c1d3f3..65d100bc7 100644
--- a/lib/sqlalchemy/ext/declarative/api.py
+++ b/lib/sqlalchemy/ext/declarative/api.py
@@ -82,10 +82,11 @@ class DeclarativeMeta(type):
 
 
 def synonym_for(name, map_column=False):
-    """Decorator that produces an :func:`.orm.synonym` attribute in conjunction
+    """Decorator that produces an :func:`_orm.synonym`
+    attribute in conjunction
     with a Python descriptor.
 
-    The function being decorated is passed to :func:`.orm.synonym` as the
+    The function being decorated is passed to :func:`_orm.synonym` as the
     :paramref:`.orm.synonym.descriptor` parameter::
 
         class MyClass(Base):
@@ -107,7 +108,7 @@ def synonym_for(name, map_column=False):
 
         :ref:`synonyms` - Overview of synonyms
 
-        :func:`.orm.synonym` - the mapper-level function
+        :func:`_orm.synonym` - the mapper-level function
 
         :ref:`mapper_hybrids` - The Hybrid Attribute extension provides an
         updated approach to augmenting attribute behavior more flexibly than
@@ -323,7 +324,7 @@ def declarative_base(
 
     :param class_registry: optional dictionary that will serve as the
       registry of class names-> mapped classes when string names
-      are used to identify classes inside of :func:`.relationship`
+      are used to identify classes inside of :func:`_orm.relationship`
       and others.  Allows two or more declarative base classes
       to share the same registry of class names for simplified
       inter-base relationships.
@@ -505,7 +506,7 @@ class AbstractConcreteBase(ConcreteBase):
 
         .. seealso::
 
-            :func:`.orm.configure_mappers`
+            :func:`_orm.configure_mappers`
 
 
     Example::
@@ -656,17 +657,17 @@ class DeferredReflection(object):
     a deferred reflection step.
 
     Normally, declarative can be used with reflection by
-    setting a :class:`.Table` object using autoload=True
+    setting a :class:`_schema.Table` object using autoload=True
     as the ``__table__`` attribute on a declarative class.
-    The caveat is that the :class:`.Table` must be fully
+    The caveat is that the :class:`_schema.Table` must be fully
     reflected, or at the very least have a primary key column,
     at the point at which a normal declarative mapping is
-    constructed, meaning the :class:`.Engine` must be available
+    constructed, meaning the :class:`_engine.Engine` must be available
     at class declaration time.
 
     The :class:`.DeferredReflection` mixin moves the construction
     of mappers to be at a later point, after a specific
-    method is called which first reflects all :class:`.Table`
+    method is called which first reflects all :class:`_schema.Table`
     objects created so far.   Classes can define it as such::
 
         from sqlalchemy.ext.declarative import declarative_base
@@ -720,7 +721,7 @@ class DeferredReflection(object):
 
     @classmethod
     def prepare(cls, engine):
-        """Reflect all :class:`.Table` objects for all current
+        """Reflect all :class:`_schema.Table` objects for all current
         :class:`.DeferredReflection` subclasses"""
 
         to_map = _DeferredMapperConfig.classes_for_base(cls)
diff --git a/lib/sqlalchemy/ext/declarative/clsregistry.py b/lib/sqlalchemy/ext/declarative/clsregistry.py
index 219c4ba2e..20de3c636 100644
--- a/lib/sqlalchemy/ext/declarative/clsregistry.py
+++ b/lib/sqlalchemy/ext/declarative/clsregistry.py
@@ -7,7 +7,7 @@
 """Routines to handle the string class registry used by declarative.
 
 This system allows specification of classes and expressions used in
-:func:`.relationship` using strings.
+:func:`_orm.relationship` using strings.
 
 """
 import weakref
diff --git a/lib/sqlalchemy/ext/horizontal_shard.py b/lib/sqlalchemy/ext/horizontal_shard.py
index 56553c83d..cfb2fd687 100644
--- a/lib/sqlalchemy/ext/horizontal_shard.py
+++ b/lib/sqlalchemy/ext/horizontal_shard.py
@@ -197,7 +197,7 @@ class ShardedSession(Session):
         possible identity tokens (e.g. shard ids).
 
         .. versionchanged:: 1.4  Moved :meth:`.Session._identity_lookup` from
-           the :class:`.Query` object to the :class:`.Session`.
+           the :class:`_query.Query` object to the :class:`.Session`.
 
         """
 
diff --git a/lib/sqlalchemy/ext/hybrid.py b/lib/sqlalchemy/ext/hybrid.py
index 7c523edbd..9f73b5d31 100644
--- a/lib/sqlalchemy/ext/hybrid.py
+++ b/lib/sqlalchemy/ext/hybrid.py
@@ -75,7 +75,8 @@ returns a new SQL expression::
     FROM interval
     WHERE interval."end" - interval.start > :param_1
 
-ORM methods such as :meth:`~.Query.filter_by` generally use ``getattr()`` to
+ORM methods such as :meth:`_query.Query.filter_by`
+generally use ``getattr()`` to
 locate attributes, so can also be used with hybrid attributes::
 
     >>> print(Session().query(Interval).filter_by(length=5))
@@ -213,10 +214,10 @@ Allowing Bulk ORM Update
 ------------------------
 
 A hybrid can define a custom "UPDATE" handler for when using the
-:meth:`.Query.update` method, allowing the hybrid to be used in the
+:meth:`_query.Query.update` method, allowing the hybrid to be used in the
 SET clause of the update.
 
-Normally, when using a hybrid with :meth:`.Query.update`, the SQL
+Normally, when using a hybrid with :meth:`_query.Query.update`, the SQL
 expression is used as the column that's the target of the SET.  If our
 ``Interval`` class had a hybrid ``start_point`` that linked to
 ``Interval.start``, this could be substituted directly::
@@ -225,7 +226,7 @@ expression is used as the column that's the target of the SET.  If our
 
 However, when using a composite hybrid like ``Interval.length``, this
 hybrid represents more than one column.   We can set up a handler that will
-accommodate a value passed to :meth:`.Query.update` which can affect
+accommodate a value passed to :meth:`_query.Query.update` which can affect
 this, using the :meth:`.hybrid_property.update_expression` decorator.
 A handler that works similarly to our setter would be::
 
@@ -628,9 +629,11 @@ measurement, currencies and encrypted passwords.
 Building Transformers
 ----------------------
 
-A *transformer* is an object which can receive a :class:`.Query` object and
-return a new one.   The :class:`.Query` object includes a method
-:meth:`.with_transformation` that returns a new :class:`.Query` transformed by
+A *transformer* is an object which can receive a :class:`_query.Query`
+object and
+return a new one.   The :class:`_query.Query` object includes a method
+:meth:`.with_transformation` that returns a new :class:`_query.Query`
+transformed by
 the given function.
 
 We can combine this with the :class:`.Comparator` class to produce one type
@@ -665,10 +668,11 @@ simple::
             return self.parent.parent
 
 For the expression, things are not so clear.   We'd need to construct a
-:class:`.Query` where we :meth:`~.Query.join` twice along ``Node.parent`` to
+:class:`_query.Query` where we :meth:`_query.Query.join` twice along ``Node.
+parent`` to
 get to the ``grandparent``.   We can instead return a transforming callable
 that we'll combine with the :class:`.Comparator` class to receive any
-:class:`.Query` object, and return a new one that's joined to the
+:class:`_query.Query` object, and return a new one that's joined to the
 ``Node.parent`` attribute and filtered based on the given criterion::
 
     from sqlalchemy.ext.hybrid import Comparator
@@ -704,9 +708,10 @@ transforming callable, which then runs the given comparison operation in a
 particular context. Such as, in the example above, the ``operate`` method is
 called, given the :attr:`.Operators.eq` callable as well as the right side of
 the comparison ``Node(id=5)``.  A function ``transform`` is then returned which
-will transform a :class:`.Query` first to join to ``Node.parent``, then to
+will transform a :class:`_query.Query` first to join to ``Node.parent``,
+then to
 compare ``parent_alias`` using :attr:`.Operators.eq` against the left and right
-sides, passing into :class:`.Query.filter`:
+sides, passing into :class:`_query.Query.filter`:
 
 .. sourcecode:: pycon+sql
 
@@ -783,7 +788,7 @@ HYBRID_METHOD = util.symbol("HYBRID_METHOD")
 
    .. seealso::
 
-    :attr:`.Mapper.all_orm_attributes`
+    :attr:`_orm.Mapper.all_orm_attributes`
 
 """
 
@@ -796,7 +801,7 @@ HYBRID_PROPERTY = util.symbol("HYBRID_PROPERTY")
 
    .. seealso::
 
-    :attr:`.Mapper.all_orm_attributes`
+    :attr:`_orm.Mapper.all_orm_attributes`
 
 """
 
diff --git a/lib/sqlalchemy/ext/indexable.py b/lib/sqlalchemy/ext/indexable.py
index 6eb7e1185..f58acceeb 100644
--- a/lib/sqlalchemy/ext/indexable.py
+++ b/lib/sqlalchemy/ext/indexable.py
@@ -6,20 +6,20 @@
 # the MIT License: http://www.opensource.org/licenses/mit-license.php
 
 """Define attributes on ORM-mapped classes that have "index" attributes for
-columns with :class:`~.types.Indexable` types.
+columns with :class:`_types.Indexable` types.
 
 "index" means the attribute is associated with an element of an
-:class:`~.types.Indexable` column with the predefined index to access it.
-The :class:`~.types.Indexable` types include types such as
-:class:`~.types.ARRAY`, :class:`~.types.JSON` and
-:class:`~.postgresql.HSTORE`.
+:class:`_types.Indexable` column with the predefined index to access it.
+The :class:`_types.Indexable` types include types such as
+:class:`_types.ARRAY`, :class:`_types.JSON` and
+:class:`_postgresql.HSTORE`.
 
 
 
 The :mod:`~sqlalchemy.ext.indexable` extension provides
-:class:`~.schema.Column`-like interface for any element of an
-:class:`~.types.Indexable` typed column. In simple cases, it can be
-treated as a :class:`~.schema.Column` - mapped attribute.
+:class:`_schema.Column`-like interface for any element of an
+:class:`_types.Indexable` typed column. In simple cases, it can be
+treated as a :class:`_schema.Column` - mapped attribute.
 
 
 .. versionadded:: 1.1
@@ -192,7 +192,7 @@ where we want to also include automatic casting plus ``astext()``::
             return expr.astext.cast(self.cast_type)
 
 The above subclass can be used with the PostgreSQL-specific
-version of :class:`.postgresql.JSON`::
+version of :class:`_postgresql.JSON`::
 
     from sqlalchemy import Column, Integer
     from sqlalchemy.ext.declarative import declarative_base
@@ -234,7 +234,7 @@ __all__ = ["index_property"]
 
 class index_property(hybrid_property):  # noqa
     """A property generator. The generated property describes an object
-    attribute that corresponds to an :class:`~.types.Indexable`
+    attribute that corresponds to an :class:`_types.Indexable`
     column.
 
     .. versionadded:: 1.1
diff --git a/lib/sqlalchemy/ext/mutable.py b/lib/sqlalchemy/ext/mutable.py
index 5523fe75d..32a22a495 100644
--- a/lib/sqlalchemy/ext/mutable.py
+++ b/lib/sqlalchemy/ext/mutable.py
@@ -39,7 +39,7 @@ JSON strings before being persisted::
 The usage of ``json`` is only for the purposes of example. The
 :mod:`sqlalchemy.ext.mutable` extension can be used
 with any type whose target Python type may be mutable, including
-:class:`.PickleType`, :class:`.postgresql.ARRAY`, etc.
+:class:`.PickleType`, :class:`_postgresql.ARRAY`, etc.
 
 When using the :mod:`sqlalchemy.ext.mutable` extension, the value itself
 tracks all parents which reference it.  Below, we illustrate a simple
@@ -270,7 +270,7 @@ and to also route attribute set events via ``__setattr__`` to the
             return not self.__eq__(other)
 
 The :class:`.MutableComposite` class uses a Python metaclass to automatically
-establish listeners for any usage of :func:`.orm.composite` that specifies our
+establish listeners for any usage of :func:`_orm.composite` that specifies our
 ``Point`` type. Below, when ``Point`` is mapped to the ``Vertex`` class,
 listeners are established which will route change events from ``Point``
 objects to each of the ``Vertex.start`` and ``Vertex.end`` attributes::
diff --git a/lib/sqlalchemy/ext/orderinglist.py b/lib/sqlalchemy/ext/orderinglist.py
index ac430c6b8..7b6b77997 100644
--- a/lib/sqlalchemy/ext/orderinglist.py
+++ b/lib/sqlalchemy/ext/orderinglist.py
@@ -11,7 +11,7 @@ elements.
 :author: Jason Kirtland
 
 ``orderinglist`` is a helper for mutable ordered relationships.  It will
-intercept list operations performed on a :func:`.relationship`-managed
+intercept list operations performed on a :func:`_orm.relationship`-managed
 collection and
 automatically synchronize changes in list position onto a target scalar
 attribute.
@@ -86,7 +86,7 @@ With the above mapping the ``Bullet.position`` attribute is managed::
 The :class:`.OrderingList` construct only works with **changes** to a
 collection, and not the initial load from the database, and requires that the
 list be sorted when loaded.  Therefore, be sure to specify ``order_by`` on the
-:func:`.relationship` against the target ordering attribute, so that the
+:func:`_orm.relationship` against the target ordering attribute, so that the
 ordering is correct when first loaded.
 
 .. warning::
@@ -212,7 +212,7 @@ class OrderingList(list):
 
     The :class:`.OrderingList` object is normally set up using the
     :func:`.ordering_list` factory function, used in conjunction with
-    the :func:`.relationship` function.
+    the :func:`_orm.relationship` function.
 
     """