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

15 files changed, 433 insertions, 434 deletions

diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst
index 2191dee6e..b9b9d6fcb 100644
--- a/doc/build/core/connections.rst
+++ b/doc/build/core/connections.rst
@@ -6,41 +6,41 @@ Working with Engines and Connections
 
 .. module:: sqlalchemy.engine
 
-This section details direct usage of the :class:`.Engine`,
-:class:`.Connection`, and related objects. Its important to note that when
+This section details direct usage of the :class:`_engine.Engine`,
+:class:`_engine.Connection`, and related objects. Its important to note that when
 using the SQLAlchemy ORM, these objects are not generally accessed; instead,
 the :class:`.Session` object is used as the interface to the database.
 However, for applications that are built around direct usage of textual SQL
 statements and/or SQL expression constructs without involvement by the ORM's
-higher level management services, the :class:`.Engine` and
-:class:`.Connection` are king (and queen?) - read on.
+higher level management services, the :class:`_engine.Engine` and
+:class:`_engine.Connection` are king (and queen?) - read on.
 
 Basic Usage
 ===========
 
-Recall from :doc:`/core/engines` that an :class:`.Engine` is created via
+Recall from :doc:`/core/engines` that an :class:`_engine.Engine` is created via
 the :func:`.create_engine` call::
 
     engine = create_engine('mysql://scott:tiger@localhost/test')
 
 The typical usage of :func:`.create_engine()` is once per particular database
 URL, held globally for the lifetime of a single application process. A single
-:class:`.Engine` manages many individual :term:`DBAPI` connections on behalf of
+:class:`_engine.Engine` manages many individual :term:`DBAPI` connections on behalf of
 the process and is intended to be called upon in a concurrent fashion. The
-:class:`.Engine` is **not** synonymous to the DBAPI ``connect`` function, which
-represents just one connection resource - the :class:`.Engine` is most
+:class:`_engine.Engine` is **not** synonymous to the DBAPI ``connect`` function, which
+represents just one connection resource - the :class:`_engine.Engine` is most
 efficient when created just once at the module level of an application, not
 per-object or per-function call.
 
 .. sidebar:: tip
 
-    When using an :class:`.Engine` with multiple Python processes, such as when
+    When using an :class:`_engine.Engine` with multiple Python processes, such as when
     using ``os.fork`` or Python ``multiprocessing``, it's important that the
     engine is initialized per process.  See :ref:`pooling_multiprocessing` for
     details.
 
-The most basic function of the :class:`.Engine` is to provide access to a
-:class:`.Connection`, which can then invoke SQL statements.   To emit
+The most basic function of the :class:`_engine.Engine` is to provide access to a
+:class:`_engine.Connection`, which can then invoke SQL statements.   To emit
 a textual statement to the database looks like::
 
     from sqlalchemy import text
@@ -50,12 +50,12 @@ a textual statement to the database looks like::
         for row in result:
             print("username:", row['username'])
 
-Above, the :meth:`.Engine.connect` method returns a :class:`.Connection`
+Above, the :meth:`_engine.Engine.connect` method returns a :class:`_engine.Connection`
 object, and by using it in a Python context manager (e.g. the ``with:``
-statement) the :meth:`.Connection.close` method is automatically invoked at the
-end of the block.  The :class:`.Connection`, is a **proxy** object for an
+statement) the :meth:`_engine.Connection.close` method is automatically invoked at the
+end of the block.  The :class:`_engine.Connection`, is a **proxy** object for an
 actual DBAPI connection. The DBAPI connection is retrieved from the connection
-pool at the point at which :class:`.Connection` is created.
+pool at the point at which :class:`_engine.Connection` is created.
 
 The object returned is known as :class:`.ResultProxy`, which
 references a DBAPI cursor and provides methods for fetching rows
@@ -65,7 +65,7 @@ exhausted.  A :class:`.ResultProxy` that returns no rows, such as that of
 an UPDATE statement (without any returned rows),
 releases cursor resources immediately upon construction.
 
-When the :class:`.Connection` is closed at the end of the ``with:`` block, the
+When the :class:`_engine.Connection` is closed at the end of the ``with:`` block, the
 referenced DBAPI connection is :term:`released` to the connection pool.   From
 the perspective of the database itself, the connection pool will not actually
 "close" the connection assuming the pool has room to store this connection  for
@@ -78,8 +78,8 @@ its next use.
    2.0 with a newly refined object known as :class:`.future.Result`.
 
 Our example above illustrated the execution of a textual SQL string, which
-should be invoked by using the :func:`.text` construct to indicate that
-we'd like to use textual SQL.  The :meth:`~.Connection.execute` method can of
+should be invoked by using the :func:`_expression.text` construct to indicate that
+we'd like to use textual SQL.  The :meth:`_engine.Connection.execute` method can of
 course accommodate more than that, including the variety of SQL expression
 constructs described in :ref:`sqlexpression_toplevel`.
 
@@ -90,14 +90,14 @@ Using Transactions
 .. note::
 
   This section describes how to use transactions when working directly
-  with :class:`.Engine` and :class:`.Connection` objects. When using the
+  with :class:`_engine.Engine` and :class:`_engine.Connection` objects. When using the
   SQLAlchemy ORM, the public API for transaction control is via the
   :class:`.Session` object, which makes usage of the :class:`.Transaction`
   object internally. See :ref:`unitofwork_transaction` for further
   information.
 
-The :class:`~sqlalchemy.engine.Connection` object provides a :meth:`~.Connection.begin`
-method which returns a :class:`.Transaction` object.  Like the :class:`.Connection`
+The :class:`~sqlalchemy.engine.Connection` object provides a :meth:`_engine.Connection.begin`
+method which returns a :class:`.Transaction` object.  Like the :class:`_engine.Connection`
 itself, this object is usually used within a Python ``with:`` block so
 that its scope is managed::
 
@@ -106,8 +106,8 @@ that its scope is managed::
             r1 = connection.execute(table1.select())
             connection.execute(table1.insert(), {"col1": 7, "col2": "this is some data"})
 
-The above block can be stated more simply by using the :meth:`.Engine.begin`
-method of :class:`.Engine`::
+The above block can be stated more simply by using the :meth:`_engine.Engine.begin`
+method of :class:`_engine.Engine`::
 
     # runs a transaction
     with engine.begin() as connection:
@@ -121,7 +121,7 @@ outwards.
 
 The underlying object used to represent the transaction is the
 :class:`.Transaction` object.  This object is returned by the
-:meth:`.Connection.begin` method and includes the methods
+:meth:`_engine.Connection.begin` method and includes the methods
 :meth:`.Transaction.commit` and :meth:`.Transaction.rollback`.   The context
 manager calling form, which invokes these methods automatically, is recommended
 as a best practice.
@@ -137,7 +137,7 @@ Nesting of Transaction Blocks
 
 The :class:`.Transaction` object also handles "nested" behavior by keeping
 track of the outermost begin/commit pair. In this example, two functions both
-issue a transaction on a :class:`.Connection`, but only the outermost
+issue a transaction on a :class:`_engine.Connection`, but only the outermost
 :class:`.Transaction` object actually takes effect when it is committed.
 
 .. sourcecode:: python+sql
@@ -209,10 +209,10 @@ the ORM, as the :class:`.Session` object by default always maintains an
 ongoing :class:`.Transaction`.
 
 Full control of the "autocommit" behavior is available using the generative
-:meth:`.Connection.execution_options` method provided on :class:`.Connection`
-and :class:`.Engine`, using the "autocommit" flag which will
+:meth:`_engine.Connection.execution_options` method provided on :class:`_engine.Connection`
+and :class:`_engine.Engine`, using the "autocommit" flag which will
 turn on or off the autocommit for the selected scope. For example, a
-:func:`.text` construct representing a stored procedure that commits might use
+:func:`_expression.text` construct representing a stored procedure that commits might use
 it so that a SELECT statement will issue a COMMIT::
 
     with engine.connect().execution_options(autocommit=True) as conn:
@@ -229,10 +229,10 @@ Connectionless Execution, Implicit Execution
    :ref:`migration_20_implicit_execution` for background.
 
 Recall from the first section we mentioned executing with and without explicit
-usage of :class:`.Connection`. "Connectionless" execution
+usage of :class:`_engine.Connection`. "Connectionless" execution
 refers to the usage of the ``execute()`` method on an object
-which is not a :class:`.Connection`.  This was illustrated using the
-:meth:`~.Engine.execute` method of :class:`.Engine`::
+which is not a :class:`_engine.Connection`.  This was illustrated using the
+:meth:`_engine.Engine.execute` method of :class:`_engine.Engine`::
 
     result = engine.execute(text("select username from users"))
     for row in result:
@@ -242,7 +242,7 @@ In addition to "connectionless" execution, it is also possible
 to use the :meth:`~.Executable.execute` method of
 any :class:`.Executable` construct, which is a marker for SQL expression objects
 that support execution.   The SQL expression object itself references an
-:class:`.Engine` or :class:`.Connection` known as the **bind**, which it uses
+:class:`_engine.Engine` or :class:`_engine.Connection` known as the **bind**, which it uses
 in order to provide so-called "implicit" execution services.
 
 Given a table as below::
@@ -256,7 +256,7 @@ Given a table as below::
     )
 
 Explicit execution delivers the SQL text or constructed SQL expression to the
-:meth:`~.Connection.execute` method of :class:`~sqlalchemy.engine.Connection`:
+:meth:`_engine.Connection.execute` method of :class:`~sqlalchemy.engine.Connection`:
 
 .. sourcecode:: python+sql
 
@@ -267,7 +267,7 @@ Explicit execution delivers the SQL text or constructed SQL expression to the
             # ....
 
 Explicit, connectionless execution delivers the expression to the
-:meth:`~.Engine.execute` method of :class:`~sqlalchemy.engine.Engine`:
+:meth:`_engine.Engine.execute` method of :class:`~sqlalchemy.engine.Engine`:
 
 .. sourcecode:: python+sql
 
@@ -284,9 +284,9 @@ for being invoked against the database.    The method makes usage of
 the assumption that either an
 :class:`~sqlalchemy.engine.Engine` or
 :class:`~sqlalchemy.engine.Connection` has been **bound** to the expression
-object.   By "bound" we mean that the special attribute :attr:`.MetaData.bind`
+object.   By "bound" we mean that the special attribute :attr:`_schema.MetaData.bind`
 has been used to associate a series of
-:class:`.Table` objects and all SQL constructs derived from them with a specific
+:class:`_schema.Table` objects and all SQL constructs derived from them with a specific
 engine::
 
     engine = create_engine('sqlite:///file.db')
@@ -296,23 +296,23 @@ engine::
         # ....
     result.close()
 
-Above, we associate an :class:`.Engine` with a :class:`.MetaData` object using
-the special attribute :attr:`.MetaData.bind`.  The :func:`~.sql.expression.select` construct produced
-from the :class:`.Table` object has a method :meth:`~.Executable.execute`, which will
-search for an :class:`.Engine` that's "bound" to the :class:`.Table`.
+Above, we associate an :class:`_engine.Engine` with a :class:`_schema.MetaData` object using
+the special attribute :attr:`_schema.MetaData.bind`.  The :func:`_expression.select` construct produced
+from the :class:`_schema.Table` object has a method :meth:`~.Executable.execute`, which will
+search for an :class:`_engine.Engine` that's "bound" to the :class:`_schema.Table`.
 
 Overall, the usage of "bound metadata" has three general effects:
 
 * SQL statement objects gain an :meth:`.Executable.execute` method which automatically
   locates a "bind" with which to execute themselves.
 * The ORM :class:`.Session` object supports using "bound metadata" in order
-  to establish which :class:`.Engine` should be used to invoke SQL statements
+  to establish which :class:`_engine.Engine` should be used to invoke SQL statements
   on behalf of a particular mapped class, though the :class:`.Session`
-  also features its own explicit system of establishing complex :class:`.Engine`/
+  also features its own explicit system of establishing complex :class:`_engine.Engine`/
   mapped class configurations.
-* The :meth:`.MetaData.create_all`, :meth:`.MetaData.drop_all`, :meth:`.Table.create`,
-  :meth:`.Table.drop`, and "autoload" features all make usage of the bound
-  :class:`.Engine` automatically without the need to pass it explicitly.
+* The :meth:`_schema.MetaData.create_all`, :meth:`_schema.MetaData.drop_all`, :meth:`_schema.Table.create`,
+  :meth:`_schema.Table.drop`, and "autoload" features all make usage of the bound
+  :class:`_engine.Engine` automatically without the need to pass it explicitly.
 
 .. note::
 
@@ -320,11 +320,11 @@ Overall, the usage of "bound metadata" has three general effects:
     While they offer some convenience, they are no longer required by any API and
     are never necessary.
 
-    In applications where multiple :class:`.Engine` objects are present, each one logically associated
+    In applications where multiple :class:`_engine.Engine` objects are present, each one logically associated
     with a certain set of tables (i.e. *vertical sharding*), the "bound metadata" technique can be used
-    so that individual :class:`.Table` can refer to the appropriate :class:`.Engine` automatically;
+    so that individual :class:`_schema.Table` can refer to the appropriate :class:`_engine.Engine` automatically;
     in particular this is supported within the ORM via the :class:`.Session` object
-    as a means to associate :class:`.Table` objects with an appropriate :class:`.Engine`,
+    as a means to associate :class:`_schema.Table` objects with an appropriate :class:`_engine.Engine`,
     as an alternative to using the bind arguments accepted directly by the :class:`.Session`.
 
     However, the "implicit execution" technique is not at all appropriate for use with the
@@ -349,7 +349,7 @@ In both "connectionless" examples, the
 :class:`~sqlalchemy.engine.ResultProxy` returned by the ``execute()``
 call references the :class:`~sqlalchemy.engine.Connection` used to issue
 the SQL statement. When the :class:`.ResultProxy` is closed, the underlying
-:class:`.Connection` is closed for us, resulting in the
+:class:`_engine.Connection` is closed for us, resulting in the
 DBAPI connection being returned to the pool with transactional resources removed.
 
 .. _schema_translating:
@@ -360,7 +360,7 @@ Translation of Schema Names
 To support multi-tenancy applications that distribute common sets of tables
 into multiple schemas, the
 :paramref:`.Connection.execution_options.schema_translate_map`
-execution option may be used to repurpose a set of :class:`.Table` objects
+execution option may be used to repurpose a set of :class:`_schema.Table` objects
 to render under different schema names without any changes.
 
 Given a table::
@@ -371,10 +371,10 @@ Given a table::
         Column('name', String(50))
     )
 
-The "schema" of this :class:`.Table` as defined by the
-:paramref:`.Table.schema` attribute is ``None``.  The
+The "schema" of this :class:`_schema.Table` as defined by the
+:paramref:`_schema.Table.schema` attribute is ``None``.  The
 :paramref:`.Connection.execution_options.schema_translate_map` can specify
-that all :class:`.Table` objects with a schema of ``None`` would instead
+that all :class:`_schema.Table` objects with a schema of ``None`` would instead
 render the schema as ``user_schema_one``::
 
     connection = engine.connect().execution_options(
@@ -399,18 +399,18 @@ map can specify any number of target->destination schemas::
 
 The :paramref:`.Connection.execution_options.schema_translate_map` parameter
 affects all DDL and SQL constructs generated from the SQL expression language,
-as derived from the :class:`.Table` or :class:`.Sequence` objects.
-It does **not** impact literal string SQL used via the :func:`.expression.text`
-construct nor via plain strings passed to :meth:`.Connection.execute`.
+as derived from the :class:`_schema.Table` or :class:`.Sequence` objects.
+It does **not** impact literal string SQL used via the :func:`_expression.text`
+construct nor via plain strings passed to :meth:`_engine.Connection.execute`.
 
 The feature takes effect **only** in those cases where the name of the
-schema is derived directly from that of a :class:`.Table` or :class:`.Sequence`;
+schema is derived directly from that of a :class:`_schema.Table` or :class:`.Sequence`;
 it does not impact methods where a string schema name is passed directly.
 By this pattern, it takes effect within the "can create" / "can drop" checks
-performed by methods such as :meth:`.MetaData.create_all` or
-:meth:`.MetaData.drop_all` are called, and it takes effect when
-using table reflection given a :class:`.Table` object.  However it does
-**not** affect the operations present on the :class:`.Inspector` object,
+performed by methods such as :meth:`_schema.MetaData.create_all` or
+:meth:`_schema.MetaData.drop_all` are called, and it takes effect when
+using table reflection given a :class:`_schema.Table` object.  However it does
+**not** affect the operations present on the :class:`_reflection.Inspector` object,
 as the schema name is passed to these methods explicitly.
 
 .. versionadded:: 1.1
@@ -420,17 +420,17 @@ as the schema name is passed to these methods explicitly.
 Engine Disposal
 ===============
 
-The :class:`.Engine` refers to a connection pool, which means under normal
+The :class:`_engine.Engine` refers to a connection pool, which means under normal
 circumstances, there are open database connections present while the
-:class:`.Engine` object is still resident in memory.   When an :class:`.Engine`
+:class:`_engine.Engine` object is still resident in memory.   When an :class:`_engine.Engine`
 is garbage collected, its connection pool is no longer referred to by
-that :class:`.Engine`, and assuming none of its connections are still checked
+that :class:`_engine.Engine`, and assuming none of its connections are still checked
 out, the pool and its connections will also be garbage collected, which has the
 effect of closing out the actual database connections as well.   But otherwise,
-the :class:`.Engine` will hold onto open database connections assuming
+the :class:`_engine.Engine` will hold onto open database connections assuming
 it uses the normally default pool implementation of :class:`.QueuePool`.
 
-The :class:`.Engine` is intended to normally be a permanent
+The :class:`_engine.Engine` is intended to normally be a permanent
 fixture established up-front and maintained throughout the lifespan of an
 application.  It is **not** intended to be created and disposed on a
 per-connection basis; it is instead a registry that maintains both a pool
@@ -439,45 +439,45 @@ and DBAPI in use, as well as some degree of internal caching of per-database
 resources.
 
 However, there are many cases where it is desirable that all connection resources
-referred to by the :class:`.Engine` be completely closed out.  It's
+referred to by the :class:`_engine.Engine` be completely closed out.  It's
 generally not a good idea to rely on Python garbage collection for this
-to occur for these cases; instead, the :class:`.Engine` can be explicitly disposed using
-the :meth:`.Engine.dispose` method.   This disposes of the engine's
+to occur for these cases; instead, the :class:`_engine.Engine` can be explicitly disposed using
+the :meth:`_engine.Engine.dispose` method.   This disposes of the engine's
 underlying connection pool and replaces it with a new one that's empty.
-Provided that the :class:`.Engine`
+Provided that the :class:`_engine.Engine`
 is discarded at this point and no longer used, all **checked-in** connections
 which it refers to will also be fully closed.
 
-Valid use cases for calling :meth:`.Engine.dispose` include:
+Valid use cases for calling :meth:`_engine.Engine.dispose` include:
 
 * When a program wants to release any remaining checked-in connections
   held by the connection pool and expects to no longer be connected
   to that database at all for any future operations.
 
 * When a program uses multiprocessing or ``fork()``, and an
-  :class:`.Engine` object is copied to the child process,
-  :meth:`.Engine.dispose` should be called so that the engine creates
+  :class:`_engine.Engine` object is copied to the child process,
+  :meth:`_engine.Engine.dispose` should be called so that the engine creates
   brand new database connections local to that fork.   Database connections
   generally do **not** travel across process boundaries.
 
 * Within test suites or multitenancy scenarios where many
-  ad-hoc, short-lived :class:`.Engine` objects may be created and disposed.
+  ad-hoc, short-lived :class:`_engine.Engine` objects may be created and disposed.
 
 
 Connections that are **checked out** are **not** discarded when the
 engine is disposed or garbage collected, as these connections are still
 strongly referenced elsewhere by the application.
-However, after :meth:`.Engine.dispose` is called, those
-connections are no longer associated with that :class:`.Engine`; when they
+However, after :meth:`_engine.Engine.dispose` is called, those
+connections are no longer associated with that :class:`_engine.Engine`; when they
 are closed, they will be returned to their now-orphaned connection pool
 which will ultimately be garbage collected, once all connections which refer
 to it are also no longer referenced anywhere.
 Since this process is not easy to control, it is strongly recommended that
-:meth:`.Engine.dispose` is called only after all checked out connections
+:meth:`_engine.Engine.dispose` is called only after all checked out connections
 are checked in or otherwise de-associated from their pool.
 
 An alternative for applications that are negatively impacted by the
-:class:`.Engine` object's use of connection pooling is to disable pooling
+:class:`_engine.Engine` object's use of connection pooling is to disable pooling
 entirely.  This typically incurs only a modest performance impact upon the
 use of new connections, and means that when a connection is checked in,
 it is entirely closed out and is not held in memory.  See :ref:`pool_switching`
@@ -488,12 +488,12 @@ for guidelines on how to disable pooling.
 Working with Driver SQL and Raw DBAPI Connections
 =================================================
 
-The introduction on using :meth:`.Connection.execute` made use of the
-:func:`.sql.text` construct in order to illustrate how textual SQL statements
+The introduction on using :meth:`_engine.Connection.execute` made use of the
+:func:`_expression.text` construct in order to illustrate how textual SQL statements
 may be invoked.  When working with SQLAlchemy, textual SQL is actually more
 of the exception rather than the norm, as the Core expression language
 and the ORM both abstract away the textual representation of SQL.  Hpwever, the
-:func:`.sql.text` construct itself also provides some abstraction of textual
+:func:`_expression.text` construct itself also provides some abstraction of textual
 SQL in that it normalizes how bound parameters are passed, as well as that
 it supports datatyping behavior for parameters and result set rows.
 
@@ -502,14 +502,14 @@ Invoking SQL strings directly to the driver
 
 For the use case where one wants to invoke textual SQL directly passed to the
 underlying driver (known as the :term:`DBAPI`) without any intervention
-from the :func:`.sql.text` construct, the :meth:`.Connection.exec_driver_sql`
+from the :func:`_expression.text` construct, the :meth:`_engine.Connection.exec_driver_sql`
 method may be used::
 
     with engine.connect() as conn:
         conn.exec_driver_sql("SET param='bar'")
 
 
-.. versionadded:: 1.4  Added the :meth:`.Connection.exec_driver_sql` method.
+.. versionadded:: 1.4  Added the :meth:`_engine.Connection.exec_driver_sql` method.
 
 Working with the DBAPI cursor directly
 --------------------------------------
@@ -520,8 +520,8 @@ as dealing with multiple result sets.  In these cases, it's just as expedient
 to deal with the raw DBAPI connection directly.
 
 The most common way to access the raw DBAPI connection is to get it
-from an already present :class:`.Connection` object directly.  It is
-present using the :attr:`.Connection.connection` attribute::
+from an already present :class:`_engine.Connection` object directly.  It is
+present using the :attr:`_engine.Connection.connection` attribute::
 
     connection = engine.connect()
     dbapi_conn = connection.connection
@@ -529,17 +529,17 @@ present using the :attr:`.Connection.connection` attribute::
 The DBAPI connection here is actually a "proxied" in terms of the
 originating connection pool, however this is an implementation detail
 that in most cases can be ignored.    As this DBAPI connection is still
-contained within the scope of an owning :class:`.Connection` object, it is
-best to make use of the :class:`.Connection` object for most features such
-as transaction control as well as calling the :meth:`.Connection.close`
+contained within the scope of an owning :class:`_engine.Connection` object, it is
+best to make use of the :class:`_engine.Connection` object for most features such
+as transaction control as well as calling the :meth:`_engine.Connection.close`
 method; if these operations are performed on the DBAPI connection directly,
-the owning :class:`.Connection` will not be aware of these changes in state.
+the owning :class:`_engine.Connection` will not be aware of these changes in state.
 
 To overcome the limitations imposed by the DBAPI connection that is
-maintained by an owning :class:`.Connection`, a DBAPI connection is also
+maintained by an owning :class:`_engine.Connection`, a DBAPI connection is also
 available without the need to procure a
-:class:`.Connection` first, using the :meth:`.Engine.raw_connection` method
-of :class:`.Engine`::
+:class:`_engine.Connection` first, using the :meth:`_engine.Engine.raw_connection` method
+of :class:`_engine.Engine`::
 
     dbapi_conn = engine.raw_connection()
 
diff --git a/doc/build/core/constraints.rst b/doc/build/core/constraints.rst
index c077cd837..4abe7709d 100644
--- a/doc/build/core/constraints.rst
+++ b/doc/build/core/constraints.rst
@@ -8,7 +8,7 @@ Defining Constraints and Indexes
 ================================
 
 This section will discuss SQL :term:`constraints` and indexes.  In SQLAlchemy
-the key classes include :class:`.ForeignKeyConstraint` and :class:`.Index`.
+the key classes include :class:`_schema.ForeignKeyConstraint` and :class:`.Index`.
 
 .. _metadata_foreignkeys:
 
@@ -111,11 +111,11 @@ rendered "inline" within the CREATE TABLE statement, such as:
 
 The ``CONSTRAINT .. FOREIGN KEY`` directive is used to create the constraint
 in an "inline" fashion within the CREATE TABLE definition.   The
-:meth:`.MetaData.create_all` and :meth:`.MetaData.drop_all` methods do
-this by default, using a topological sort of all the :class:`.Table` objects
+:meth:`_schema.MetaData.create_all` and :meth:`_schema.MetaData.drop_all` methods do
+this by default, using a topological sort of all the :class:`_schema.Table` objects
 involved such that tables are created and dropped in order of their foreign
 key dependency (this sort is also available via the
-:attr:`.MetaData.sorted_tables` accessor).
+:attr:`_schema.MetaData.sorted_tables` accessor).
 
 This approach can't work when two or more foreign key constraints are
 involved in a "dependency cycle", where a set of tables
@@ -144,7 +144,7 @@ most forms of ALTER.  Given a schema like::
         )
     )
 
-When we call upon :meth:`.MetaData.create_all` on a backend such as the
+When we call upon :meth:`_schema.MetaData.create_all` on a backend such as the
 PostgreSQL backend, the cycle between these two tables is resolved and the
 constraints are created separately:
 
@@ -199,8 +199,8 @@ This error only applies to the DROP case as we can emit "ADD CONSTRAINT"
 in the CREATE case without a name; the database typically assigns one
 automatically.
 
-The :paramref:`.ForeignKeyConstraint.use_alter` and
-:paramref:`.ForeignKey.use_alter` keyword arguments can be used
+The :paramref:`_schema.ForeignKeyConstraint.use_alter` and
+:paramref:`_schema.ForeignKey.use_alter` keyword arguments can be used
 to manually resolve dependency cycles.  We can add this flag only to
 the ``'element'`` table as follows::
 
@@ -238,8 +238,8 @@ and not the other one:
     FOREIGN KEY(parent_node_id) REFERENCES node (node_id)
     {stop}
 
-:paramref:`.ForeignKeyConstraint.use_alter` and
-:paramref:`.ForeignKey.use_alter`, when used in conjunction with a drop
+:paramref:`_schema.ForeignKeyConstraint.use_alter` and
+:paramref:`_schema.ForeignKey.use_alter`, when used in conjunction with a drop
 operation, will require that the constraint is named, else an error
 like the following is generated::
 
@@ -247,14 +247,14 @@ like the following is generated::
     ForeignKeyConstraint(...); it has no name
 
 .. versionchanged:: 1.0.0 - The DDL system invoked by
-   :meth:`.MetaData.create_all`
-   and :meth:`.MetaData.drop_all` will now automatically resolve mutually
+   :meth:`_schema.MetaData.create_all`
+   and :meth:`_schema.MetaData.drop_all` will now automatically resolve mutually
    depdendent foreign keys between tables declared by
-   :class:`.ForeignKeyConstraint` and :class:`.ForeignKey` objects, without
-   the need to explicitly set the :paramref:`.ForeignKeyConstraint.use_alter`
+   :class:`_schema.ForeignKeyConstraint` and :class:`_schema.ForeignKey` objects, without
+   the need to explicitly set the :paramref:`_schema.ForeignKeyConstraint.use_alter`
    flag.
 
-.. versionchanged:: 1.0.0 - The :paramref:`.ForeignKeyConstraint.use_alter`
+.. versionchanged:: 1.0.0 - The :paramref:`_schema.ForeignKeyConstraint.use_alter`
    flag can be used with an un-named constraint; only the DROP operation
    will emit a specific error when actually called upon.
 
@@ -370,9 +370,9 @@ MySQL.
 PRIMARY KEY Constraint
 ----------------------
 
-The primary key constraint of any :class:`.Table` object is implicitly
-present, based on the :class:`.Column` objects that are marked with the
-:paramref:`.Column.primary_key` flag.   The :class:`.PrimaryKeyConstraint`
+The primary key constraint of any :class:`_schema.Table` object is implicitly
+present, based on the :class:`_schema.Column` objects that are marked with the
+:paramref:`_schema.Column.primary_key` flag.   The :class:`.PrimaryKeyConstraint`
 object provides explicit access to this constraint, which includes the
 option of being configured directly::
 
@@ -392,13 +392,13 @@ option of being configured directly::
 Setting up Constraints when using the Declarative ORM Extension
 ---------------------------------------------------------------
 
-The :class:`.Table` is the SQLAlchemy Core construct that allows one to define
+The :class:`_schema.Table` is the SQLAlchemy Core construct that allows one to define
 table metadata, which among other things can be used by the SQLAlchemy ORM
 as a target to map a class.  The :ref:`Declarative <declarative_toplevel>`
-extension allows the :class:`.Table` object to be created automatically, given
-the contents of the table primarily as a mapping of :class:`.Column` objects.
+extension allows the :class:`_schema.Table` object to be created automatically, given
+the contents of the table primarily as a mapping of :class:`_schema.Column` objects.
 
-To apply table-level constraint objects such as :class:`.ForeignKeyConstraint`
+To apply table-level constraint objects such as :class:`_schema.ForeignKeyConstraint`
 to a table defined using Declarative, use the ``__table_args__`` attribute,
 described at :ref:`declarative_table_args`.
 
@@ -420,7 +420,7 @@ specify the name of an existing constraint that is to be dropped or modified.
 Constraints can be named explicitly using the :paramref:`.Constraint.name` parameter,
 and for indexes the :paramref:`.Index.name` parameter.  However, in the
 case of constraints this parameter is optional.  There are also the use
-cases of using the :paramref:`.Column.unique` and :paramref:`.Column.index`
+cases of using the :paramref:`_schema.Column.unique` and :paramref:`_schema.Column.index`
 parameters which create :class:`.UniqueConstraint` and :class:`.Index` objects
 without an explicit name being specified.
 
@@ -437,19 +437,19 @@ and :class:`.Index` objects, automated naming schemes can be constructed
 using events.  This approach has the advantage that constraints will get
 a consistent naming scheme without the need for explicit name parameters
 throughout the code, and also that the convention takes place just as well
-for those constraints and indexes produced by the :paramref:`.Column.unique`
-and :paramref:`.Column.index` parameters.  As of SQLAlchemy 0.9.2 this
+for those constraints and indexes produced by the :paramref:`_schema.Column.unique`
+and :paramref:`_schema.Column.index` parameters.  As of SQLAlchemy 0.9.2 this
 event-based approach is included, and can be configured using the argument
-:paramref:`.MetaData.naming_convention`.
+:paramref:`_schema.MetaData.naming_convention`.
 
-:paramref:`.MetaData.naming_convention` refers to a dictionary which accepts
+:paramref:`_schema.MetaData.naming_convention` refers to a dictionary which accepts
 the :class:`.Index` class or individual :class:`.Constraint` classes as keys,
 and Python string templates as values.   It also accepts a series of
 string-codes as alternative keys, ``"fk"``, ``"pk"``,
 ``"ix"``, ``"ck"``, ``"uq"`` for foreign key, primary key, index,
 check, and unique constraint, respectively.  The string templates in this
 dictionary are used whenever a constraint or index is associated with this
-:class:`.MetaData` object that does not have an existing name given (including
+:class:`_schema.MetaData` object that does not have an existing name given (including
 one exception case where an existing name can be further embellished).
 
 An example naming convention that suits basic cases is as follows::
@@ -465,7 +465,7 @@ An example naming convention that suits basic cases is as follows::
     metadata = MetaData(naming_convention=convention)
 
 The above convention will establish names for all constraints within
-the target :class:`.MetaData` collection.
+the target :class:`_schema.MetaData` collection.
 For example, we can observe the name produced when we create an unnamed
 :class:`.UniqueConstraint`::
 
@@ -477,7 +477,7 @@ For example, we can observe the name produced when we create an unnamed
     >>> list(user_table.constraints)[1].name
     'uq_user_name'
 
-This same feature takes effect even if we just use the :paramref:`.Column.unique`
+This same feature takes effect even if we just use the :paramref:`_schema.Column.unique`
 flag::
 
     >>> user_table = Table('user', metadata,
@@ -498,9 +498,9 @@ will be explicit when a new migration script is generated::
 The above ``"uq_user_name"`` string was copied from the :class:`.UniqueConstraint`
 object that ``--autogenerate`` located in our metadata.
 
-The default value for :paramref:`.MetaData.naming_convention` handles
+The default value for :paramref:`_schema.MetaData.naming_convention` handles
 the long-standing SQLAlchemy behavior of assigning a name to a :class:`.Index`
-object that is created using the :paramref:`.Column.index` parameter::
+object that is created using the :paramref:`_schema.Column.index` parameter::
 
     >>> from sqlalchemy.sql.schema import DEFAULT_NAMING_CONVENTION
     >>> DEFAULT_NAMING_CONVENTION
@@ -512,7 +512,7 @@ The tokens available include ``%(table_name)s``, ``%(referred_table_name)s``,
 multiple-column versions of each including ``%(column_0N_name)s``,
 ``%(column_0_N_name)s``,  ``%(referred_column_0_N_name)s`` which render all
 column names separated with or without an underscore.  The documentation for
-:paramref:`.MetaData.naming_convention` has further detail on each  of these
+:paramref:`_schema.MetaData.naming_convention` has further detail on each  of these
 conventions.
 
 When a generated name, particularly those that use the multiple-column tokens,
@@ -573,7 +573,7 @@ that as follows::
         "fk": "fk_%(fk_guid)s",
     }
 
-Above, when we create a new :class:`.ForeignKeyConstraint`, we will get a
+Above, when we create a new :class:`_schema.ForeignKeyConstraint`, we will get a
 name as follows::
 
     >>> metadata = MetaData(naming_convention=convention)
@@ -596,7 +596,7 @@ name as follows::
 
 .. seealso::
 
-    :paramref:`.MetaData.naming_convention` - for additional usage details
+    :paramref:`_schema.MetaData.naming_convention` - for additional usage details
     as well as a listing of all available naming components.
 
     `The Importance of Naming Constraints <https://alembic.sqlalchemy.org/en/latest/naming.html>`_ - in the Alembic documentation.
@@ -635,8 +635,8 @@ The above table will produce the name ``ck_foo_value_gt_5``::
     )
 
 :class:`.CheckConstraint` also supports the ``%(columns_0_name)s``
-token; we can make use of this by ensuring we use a :class:`.Column` or
-:func:`.sql.expression.column` element within the constraint's expression,
+token; we can make use of this by ensuring we use a :class:`_schema.Column` or
+:func:`_expression.column` element within the constraint's expression,
 either by declaring the constraint separate from the table::
 
     metadata = MetaData(
@@ -649,7 +649,7 @@ either by declaring the constraint separate from the table::
 
     CheckConstraint(foo.c.value > 5)
 
-or by using a :func:`.sql.expression.column` inline::
+or by using a :func:`_expression.column` inline::
 
     from sqlalchemy import column
 
@@ -833,9 +833,9 @@ INDEX" is issued right after the create statements for the table:
     CREATE INDEX idx_col34 ON mytable (col3, col4){stop}
 
 Note in the example above, the :class:`.Index` construct is created
-externally to the table which it corresponds, using :class:`.Column`
+externally to the table which it corresponds, using :class:`_schema.Column`
 objects directly.  :class:`.Index` also supports
-"inline" definition inside the :class:`.Table`, using string names to
+"inline" definition inside the :class:`_schema.Table`, using string names to
 identify columns::
 
     meta = MetaData()
@@ -869,7 +869,7 @@ Functional Indexes
 
 :class:`.Index` supports SQL and function expressions, as supported by the
 target backend.  To create an index against a column using a descending
-value, the :meth:`.ColumnElement.desc` modifier may be used::
+value, the :meth:`_expression.ColumnElement.desc` modifier may be used::
 
     from sqlalchemy import Index
 
diff --git a/doc/build/core/custom_types.rst b/doc/build/core/custom_types.rst
index 22c9e702a..740d1593f 100644
--- a/doc/build/core/custom_types.rst
+++ b/doc/build/core/custom_types.rst
@@ -28,7 +28,7 @@ can be associated with any type::
     def compile_binary_sqlite(type_, compiler, **kw):
         return "BLOB"
 
-The above code allows the usage of :class:`.types.BINARY`, which
+The above code allows the usage of :class:`_types.BINARY`, which
 will produce the string ``BINARY`` against all backends except SQLite,
 in which case it will produce ``BLOB``.
 
@@ -349,7 +349,7 @@ data into particular formats.
 Any :class:`.TypeEngine`, :class:`.UserDefinedType` or :class:`.TypeDecorator` subclass
 can include implementations of
 :meth:`.TypeEngine.bind_expression` and/or :meth:`.TypeEngine.column_expression`, which
-when defined to return a non-``None`` value should return a :class:`.ColumnElement`
+when defined to return a non-``None`` value should return a :class:`_expression.ColumnElement`
 expression to be injected into the SQL statement, either surrounding
 bound parameters or a column expression.  For example, to build a ``Geometry``
 type which will apply the PostGIS function ``ST_GeomFromText`` to all outgoing
@@ -370,8 +370,8 @@ in conjunction with :data:`~.sqlalchemy.sql.expression.func`::
         def column_expression(self, col):
             return func.ST_AsText(col, type_=self)
 
-We can apply the ``Geometry`` type into :class:`.Table` metadata
-and use it in a :func:`~.sql.expression.select` construct::
+We can apply the ``Geometry`` type into :class:`_schema.Table` metadata
+and use it in a :func:`_expression.select` construct::
 
     geometry = Table('geometry', metadata,
                   Column('geom_id', Integer, primary_key=True),
@@ -393,7 +393,7 @@ is run on the bound parameter so that the passed-in value is converted::
 The :meth:`.TypeEngine.column_expression` method interacts with the
 mechanics of the compiler such that the SQL expression does not interfere
 with the labeling of the wrapped expression.   Such as, if we rendered
-a :func:`~.sql.expression.select` against a :func:`.label` of our expression, the string
+a :func:`_expression.select` against a :func:`.label` of our expression, the string
 label is moved to the outside of the wrapped expression::
 
     print(select([geometry.c.geom_data.label('my_data')]))
@@ -404,7 +404,7 @@ Output::
     FROM geometry
 
 Another example is we decorate
-:class:`.postgresql.BYTEA` to provide a ``PGPString``, which will make use of the
+:class:`_postgresql.BYTEA` to provide a ``PGPString``, which will make use of the
 PostgreSQL ``pgcrypto`` extension to encrypt/decrypt values
 transparently::
 
@@ -528,7 +528,7 @@ set to ``True``::
 New methods added to a :class:`.TypeEngine.Comparator` are exposed on an
 owning SQL expression
 using a ``__getattr__`` scheme, which exposes methods added to
-:class:`.TypeEngine.Comparator` onto the owning :class:`.ColumnElement`.
+:class:`.TypeEngine.Comparator` onto the owning :class:`_expression.ColumnElement`.
 For example, to add a ``log()`` function
 to integers::
 
@@ -603,12 +603,12 @@ column, we might receive back the string ``"VARCHAR"``.  SQLAlchemy's
 PostgreSQL dialect has a hardcoded mapping which links the string name
 ``"VARCHAR"`` to the SQLAlchemy :class:`.VARCHAR` class, and that's how when we
 emit a statement like ``Table('my_table', m, autoload_with=engine)``, the
-:class:`.Column` object within it would have an instance of :class:`.VARCHAR`
+:class:`_schema.Column` object within it would have an instance of :class:`.VARCHAR`
 present inside of it.
 
-The implication of this is that if a :class:`.Table` object makes use of type
+The implication of this is that if a :class:`_schema.Table` object makes use of type
 objects that don't correspond directly to the database-native type name, if we
-create a new :class:`.Table` object against a new :class:`.MetaData` collection
+create a new :class:`_schema.Table` object against a new :class:`_schema.MetaData` collection
 for this database table elsewhere using reflection, it will not have this
 datatype. For example::
 
@@ -635,7 +635,7 @@ object that was created by us directly, it is :class:`.PickleType`::
     >>> my_table.c.data.type
     PickleType()
 
-However, if we create another instance of :class:`.Table` using reflection,
+However, if we create another instance of :class:`_schema.Table` using reflection,
 the use of :class:`.PickleType` is not represented in the SQLite database we've
 created; we instead get back :class:`.BLOB`::
 
@@ -650,19 +650,19 @@ created; we instead get back :class:`.BLOB`::
     >>> my_reflected_table.c.data.type
     BLOB()
 
-Typically, when an application defines explicit :class:`.Table` metadata with
+Typically, when an application defines explicit :class:`_schema.Table` metadata with
 custom types, there is no need to use table reflection because the necessary
-:class:`.Table` metadata is already present.  However, for the case where an
+:class:`_schema.Table` metadata is already present.  However, for the case where an
 application, or a combination of them, need to make use of both explicit
-:class:`.Table` metadata which includes custom, Python-level datatypes, as well
-as :class:`.Table` objects which set up their :class:`.Column` objects as
+:class:`_schema.Table` metadata which includes custom, Python-level datatypes, as well
+as :class:`_schema.Table` objects which set up their :class:`_schema.Column` objects as
 reflected from the database, which nevertheless still need to exhibit the
 additional Python behaviors of the custom datatypes, additional steps must be
 taken to allow this.
 
 The most straightforward is to override specific columns as described at
 :ref:`reflection_overriding_columns`.  In this technique, we simply
-use reflection in combination with explicit :class:`.Column` objects for those
+use reflection in combination with explicit :class:`_schema.Column` objects for those
 columns for which we want to use a custom or decorated datatype::
 
     >>> metadata_three = MetaData()
@@ -670,9 +670,9 @@ columns for which we want to use a custom or decorated datatype::
 
 The ``my_reflected_table`` object above is reflected, and will load the
 definition of the "id" column from the SQLite database.  But for the "data"
-column, we've overridden the reflected object with an explicit :class:`.Column`
+column, we've overridden the reflected object with an explicit :class:`_schema.Column`
 definition that includes our desired in-Python datatype, the
-:class:`.PickleType`. The reflection process will leave this :class:`.Column`
+:class:`.PickleType`. The reflection process will leave this :class:`_schema.Column`
 object intact::
 
     >>> my_reflected_table.c.data.type
@@ -696,8 +696,8 @@ for example we knew that we wanted all :class:`.BLOB` datatypes to in fact be
 
 When the above code is invoked *before* any table reflection occurs (note also
 it should be invoked **only once** in the application, as it is a global rule),
-upon reflecting any :class:`.Table` that includes a column with a :class:`.BLOB`
-datatype, the resulting datatype will be stored in the :class:`.Column` object
+upon reflecting any :class:`_schema.Table` that includes a column with a :class:`.BLOB`
+datatype, the resulting datatype will be stored in the :class:`_schema.Column` object
 as :class:`.PickleType`.
 
 In practice, the above event-based approach would likely have additional rules
diff --git a/doc/build/core/ddl.rst b/doc/build/core/ddl.rst
index 46a4e1d84..f38dcf849 100644
--- a/doc/build/core/ddl.rst
+++ b/doc/build/core/ddl.rst
@@ -47,7 +47,7 @@ details.
 Controlling DDL Sequences
 -------------------------
 
-The :class:`~.schema.DDL` construct introduced previously also has the
+The :class:`_schema.DDL` construct introduced previously also has the
 ability to be invoked conditionally based on inspection of the
 database.  This feature is available using the :meth:`.DDLElement.execute_if`
 method.  For example, if we wanted to create a trigger but only on
@@ -167,8 +167,8 @@ The event-driven DDL system described in the previous section
 :ref:`schema_ddl_sequences` is available with other :class:`.DDLElement`
 objects as well.  However, when dealing with the built-in constructs
 such as :class:`.CreateIndex`, :class:`.CreateSequence`, etc, the event
-system is of **limited** use, as methods like :meth:`.Table.create` and
-:meth:`.MetaData.create_all` will invoke these constructs unconditionally.
+system is of **limited** use, as methods like :meth:`_schema.Table.create` and
+:meth:`_schema.MetaData.create_all` will invoke these constructs unconditionally.
 In a future SQLAlchemy release, the DDL event system including conditional
 execution will taken into account for built-in constructs that currently
 invoke in all cases.
@@ -220,7 +220,7 @@ While the above example is against the built-in :class:`.AddConstraint`
 and :class:`.DropConstraint` objects, the main usefulness of DDL events
 for now remains focused on the use of the :class:`.DDL` construct itself,
 as well as with user-defined subclasses of :class:`.DDLElement` that aren't
-already part of the :meth:`.MetaData.create_all`, :meth:`.Table.create`,
+already part of the :meth:`_schema.MetaData.create_all`, :meth:`_schema.Table.create`,
 and corresponding "drop" processes.
 
 .. _schema_api_ddl:
diff --git a/doc/build/core/defaults.rst b/doc/build/core/defaults.rst
index 73520bdfd..fa9bf5867 100644
--- a/doc/build/core/defaults.rst
+++ b/doc/build/core/defaults.rst
@@ -78,7 +78,7 @@ defaults)::
 Python-Executed Functions
 -------------------------
 
-The :paramref:`.Column.default` and :paramref:`.Column.onupdate` keyword arguments also accept Python
+The :paramref:`_schema.Column.default` and :paramref:`_schema.Column.onupdate` keyword arguments also accept Python
 functions. These functions are invoked at the time of insert or update if no
 other value for that column is supplied, and the value returned is used for
 the column's value. Below illustrates a crude "sequence" that assigns an
@@ -100,12 +100,12 @@ built-in capabilities of the database should normally be used, which may
 include sequence objects or other autoincrementing capabilities. For primary
 key columns, SQLAlchemy will in most cases use these capabilities
 automatically. See the API documentation for
-:class:`~sqlalchemy.schema.Column` including the :paramref:`.Column.autoincrement` flag, as
+:class:`~sqlalchemy.schema.Column` including the :paramref:`_schema.Column.autoincrement` flag, as
 well as the section on :class:`~sqlalchemy.schema.Sequence` later in this
 chapter for background on standard primary key generation techniques.
 
 To illustrate onupdate, we assign the Python ``datetime`` function ``now`` to
-the :paramref:`.Column.onupdate` attribute::
+the :paramref:`_schema.Column.onupdate` attribute::
 
     import datetime
 
@@ -128,8 +128,8 @@ executes.
 Context-Sensitive Default Functions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The Python functions used by :paramref:`.Column.default` and
-:paramref:`.Column.onupdate` may also make use of the current statement's
+The Python functions used by :paramref:`_schema.Column.default` and
+:paramref:`_schema.Column.onupdate` may also make use of the current statement's
 context in order to determine a value. The `context` of a statement is an
 internal SQLAlchemy object which contains all information about the statement
 being executed, including its source expression, the parameters associated with
@@ -152,10 +152,10 @@ otherwise not provided, and the value will be that of whatever value is present
 in the execution for the ``counter`` column, plus the number 12.
 
 For a single statement that is being executed using "executemany" style, e.g.
-with multiple parameter sets passed to :meth:`.Connection.execute`, the user-
+with multiple parameter sets passed to :meth:`_engine.Connection.execute`, the user-
 defined function is called once for each set of parameters. For the use case of
-a multi-valued :class:`~.sql.expression.Insert` construct (e.g. with more than one VALUES
-clause set up via the :meth:`.Insert.values` method), the user-defined function
+a multi-valued :class:`_expression.Insert` construct (e.g. with more than one VALUES
+clause set up via the :meth:`_expression.Insert.values` method), the user-defined function
 is also called once for each set of parameters.
 
 When the function is invoked, the special method
@@ -178,7 +178,7 @@ and returned alone.
 Client-Invoked SQL Expressions
 ------------------------------
 
-The :paramref:`.Column.default` and :paramref:`.Column.onupdate` keywords may
+The :paramref:`_schema.Column.default` and :paramref:`_schema.Column.onupdate` keywords may
 also be passed SQL expressions, which are in most cases rendered inline within the
 INSERT or UPDATE statement::
 
@@ -213,21 +213,21 @@ emitted for this table.
     ``func.now()`` returns the SQL expression object that will render the
     "NOW" function into the SQL being emitted.
 
-Default and update SQL expressions specified by :paramref:`.Column.default` and
-:paramref:`.Column.onupdate` are invoked explicitly by SQLAlchemy when an
+Default and update SQL expressions specified by :paramref:`_schema.Column.default` and
+:paramref:`_schema.Column.onupdate` are invoked explicitly by SQLAlchemy when an
 INSERT or UPDATE statement occurs, typically rendered inline within the DML
 statement except in certain cases listed below.   This is different than a
 "server side" default, which is part of the table's DDL definition, e.g. as
 part of the "CREATE TABLE" statement, which are likely more common.   For
 server side defaults, see the next section :ref:`server_defaults`.
 
-When a SQL expression indicated by :paramref:`.Column.default` is used with
+When a SQL expression indicated by :paramref:`_schema.Column.default` is used with
 primary key columns, there are some cases where SQLAlchemy must "pre-execute"
 the default generation SQL function, meaning it is invoked in a separate SELECT
 statement, and the resulting value is passed as a parameter to the INSERT.
 This only occurs for primary key columns for an INSERT statement that is being
 asked to return this primary key value, where RETURNING or ``cursor.lastrowid``
-may not be used.   An :class:`~.sql.expression.Insert` construct that specifies the
+may not be used.   An :class:`_expression.Insert` construct that specifies the
 :paramref:`~.expression.insert.inline` flag will always render default expressions
 inline.
 
@@ -250,8 +250,8 @@ column primary keys are represented in the same format).
 Server-invoked DDL-Explicit Default Expressions
 -----------------------------------------------
 
-A variant on the SQL expression default is the :paramref:`.Column.server_default`, which gets
-placed in the CREATE TABLE statement during a :meth:`.Table.create` operation:
+A variant on the SQL expression default is the :paramref:`_schema.Column.server_default`, which gets
+placed in the CREATE TABLE statement during a :meth:`_schema.Table.create` operation:
 
 .. sourcecode:: python+sql
 
@@ -269,14 +269,14 @@ A create call for the above table will produce::
         index_value integer default 0
     )
 
-The above example illustrates the two typical use cases for :paramref:`.Column.server_default`,
+The above example illustrates the two typical use cases for :paramref:`_schema.Column.server_default`,
 that of the SQL function (SYSDATE in the above example) as well as a server-side constant
 value (the integer "0" in the above example).  It is advisable to use the
-:func:`.text` construct for any literal SQL values as opposed to passing the
+:func:`_expression.text` construct for any literal SQL values as opposed to passing the
 raw value, as SQLAlchemy does not typically perform any quoting or escaping on
 these values.
 
-Like client-generated expressions, :paramref:`.Column.server_default` can accommodate
+Like client-generated expressions, :paramref:`_schema.Column.server_default` can accommodate
 SQL expressions in general, however it is expected that these will usually be simple
 functions and expressions, and not the more complex cases like an embedded SELECT.
 
@@ -305,8 +305,8 @@ and for supporting  databases may be used to indicate that the column should be
 part of a RETURNING or OUTPUT clause for the statement.    Tools such as the
 SQLAlchemy ORM then make use of this marker in order to know how to get at the
 value of the column after such an operation.   In particular, the
-:meth:`.ValuesBase.return_defaults` method can be used with an :class:`~.sql.expression.Insert`
-or :class:`.Update` construct to indicate that these values should be
+:meth:`.ValuesBase.return_defaults` method can be used with an :class:`_expression.Insert`
+or :class:`_expression.Update` construct to indicate that these values should be
 returned.
 
 For details on using :class:`.FetchedValue` with the ORM, see
@@ -354,14 +354,14 @@ value can be returned to the Python code::
     RETURNING cart_id
 
 When the :class:`~sqlalchemy.schema.Sequence` is associated with a
-:class:`.Column` as its **Python-side** default generator, the
+:class:`_schema.Column` as its **Python-side** default generator, the
 :class:`.Sequence` will also be subject to "CREATE SEQUENCE" and "DROP
-SEQUENCE" DDL when similar DDL is emitted for the owning :class:`.Table`.
+SEQUENCE" DDL when similar DDL is emitted for the owning :class:`_schema.Table`.
 This is a limited scope convenience feature that does not accommodate for
-inheritance of other aspects of the :class:`.MetaData`, such as the default
+inheritance of other aspects of the :class:`_schema.MetaData`, such as the default
 schema.  Therefore, it is best practice that for a :class:`.Sequence` which
-is local to a certain :class:`.Column` / :class:`.Table`, that it be
-explicitly associated with the :class:`.MetaData` using the
+is local to a certain :class:`_schema.Column` / :class:`_schema.Table`, that it be
+explicitly associated with the :class:`_schema.MetaData` using the
 :paramref:`.Sequence.metadata` parameter.  See the section
 :ref:`sequence_metadata` for more background on this.
 
@@ -370,7 +370,7 @@ Associating a Sequence on a SERIAL column
 
 PostgreSQL's SERIAL datatype is an auto-incrementing type that implies
 the implicit creation of a PostgreSQL sequence when CREATE TABLE is emitted.
-If a :class:`.Column` specifies an explicit :class:`.Sequence` object
+If a :class:`_schema.Column` specifies an explicit :class:`.Sequence` object
 which also specifies a true value for the :paramref:`.Sequence.optional`
 boolean flag, the :class:`.Sequence` will not take effect under PostgreSQL,
 and the SERIAL datatype will proceed normally.   Instead, the :class:`.Sequence`
@@ -416,7 +416,7 @@ example of associating a :class:`.Sequence` with a table as follows::
 
 While the above is a prominent idiomatic pattern, it is recommended that
 the :class:`.Sequence` in most cases be explicitly associated with the
-:class:`.MetaData`, using the :paramref:`.Sequence.metadata` parameter::
+:class:`_schema.MetaData`, using the :paramref:`.Sequence.metadata` parameter::
 
     table = Table("cartitems", meta,
         Column(
@@ -430,32 +430,32 @@ the :class:`.Sequence` in most cases be explicitly associated with the
 The :class:`.Sequence` object is a first class
 schema construct that can exist independently of any table in a database, and
 can also be shared among tables.   Therefore SQLAlchemy does not implicitly
-modify the :class:`.Sequence` when it is associated with a :class:`.Column`
+modify the :class:`.Sequence` when it is associated with a :class:`_schema.Column`
 object as either the Python-side or server-side default  generator.  While the
 CREATE SEQUENCE / DROP SEQUENCE DDL is emitted for a  :class:`.Sequence`
 defined as a Python side generator at the same time the table itself is subject
 to CREATE or DROP, this is a convenience feature that does not imply that the
-:class:`.Sequence` is fully associated with the :class:`.MetaData` object.
+:class:`.Sequence` is fully associated with the :class:`_schema.MetaData` object.
 
-Explicitly associating the :class:`.Sequence` with :class:`.MetaData`
+Explicitly associating the :class:`.Sequence` with :class:`_schema.MetaData`
 allows for the following behaviors:
 
-* The :class:`.Sequence` will inherit the :paramref:`.MetaData.schema`
-  parameter specified to the target :class:`.MetaData`, which
+* The :class:`.Sequence` will inherit the :paramref:`_schema.MetaData.schema`
+  parameter specified to the target :class:`_schema.MetaData`, which
   affects the production of CREATE / DROP DDL, if any.
 
 * The :meth:`.Sequence.create` and :meth:`.Sequence.drop` methods
-  automatically use the engine bound to the :class:`.MetaData`
+  automatically use the engine bound to the :class:`_schema.MetaData`
   object, if any.
 
-* The :meth:`.MetaData.create_all` and :meth:`.MetaData.drop_all`
+* The :meth:`_schema.MetaData.create_all` and :meth:`_schema.MetaData.drop_all`
   methods will emit CREATE / DROP for this :class:`.Sequence`,
   even if the :class:`.Sequence` is not associated with any
-  :class:`.Table` / :class:`.Column` that's a member of this
-  :class:`.MetaData`.
+  :class:`_schema.Table` / :class:`_schema.Column` that's a member of this
+  :class:`_schema.MetaData`.
 
 Since the vast majority of cases that deal with :class:`.Sequence` expect
-that :class:`.Sequence` to be fully "owned" by the associated :class:`.Table`
+that :class:`.Sequence` to be fully "owned" by the associated :class:`_schema.Table`
 and that options like default schema are propagated, setting the
 :paramref:`.Sequence.metadata` parameter should be considered a best practice.
 
@@ -466,24 +466,24 @@ Associating a Sequence as the Server Side Default
    database.  It does not work with Oracle.
 
 The preceding sections illustrate how to associate a :class:`.Sequence` with a
-:class:`.Column` as the **Python side default generator**::
+:class:`_schema.Column` as the **Python side default generator**::
 
     Column(
         "cart_id", Integer, Sequence('cart_id_seq', metadata=meta),
         primary_key=True)
 
 In the above case, the :class:`.Sequence` will automatically be subject
-to CREATE SEQUENCE / DROP SEQUENCE DDL when the related :class:`.Table`
+to CREATE SEQUENCE / DROP SEQUENCE DDL when the related :class:`_schema.Table`
 is subject to CREATE / DROP.  However, the sequence will **not** be present
 as the server-side default for the column when CREATE TABLE is emitted.
 
 If we want the sequence to be used as a server-side default,
 meaning it takes place even if we emit INSERT commands to the table from
-the SQL command line, we can use the :paramref:`.Column.server_default`
+the SQL command line, we can use the :paramref:`_schema.Column.server_default`
 parameter in conjunction with the value-generation function of the
 sequence, available from the :meth:`.Sequence.next_value` method.  Below
 we illustrate the same :class:`.Sequence` being associated with the
-:class:`.Column` both as the Python-side default generator as well as
+:class:`_schema.Column` both as the Python-side default generator as well as
 the server-side default generator::
 
     cart_id_seq = Sequence('cart_id_seq', metadata=meta)
@@ -527,8 +527,8 @@ of the INSERT statement itself, which only works if the sequence is
 included as the Python-side default generator function.
 
 The example also associates the :class:`.Sequence` with the enclosing
-:class:`.MetaData` directly, which again ensures that the :class:`.Sequence`
-is fully associated with the parameters of the :class:`.MetaData` collection
+:class:`_schema.MetaData` directly, which again ensures that the :class:`.Sequence`
+is fully associated with the parameters of the :class:`_schema.MetaData` collection
 including the default schema, if any.
 
 .. seealso::
@@ -544,10 +544,10 @@ Computed (GENERATED ALWAYS AS) Columns
 
 .. versionadded:: 1.3.11
 
-The :class:`.Computed` construct allows a :class:`.Column` to be declared in
+The :class:`.Computed` construct allows a :class:`_schema.Column` to be declared in
 DDL as a "GENERATED ALWAYS AS" column, that is, one which has a value that is
 computed by the database server.    The construct accepts a SQL expression
-typically declared textually using a string or the :func:`.text` construct, in
+typically declared textually using a string or the :func:`_expression.text` construct, in
 a similar manner as that of :class:`.CheckConstraint`.   The SQL expression is
 then interpreted by the database server in order to determine the value for the
 column within a row.
@@ -589,14 +589,14 @@ backend; leaving it unset will use  a working default for the target backend.
 
 The :class:`.Computed` construct is a subclass of the :class:`.FetchedValue`
 object, and will set itself up as both the "server default" and "server
-onupdate" generator for the target :class:`.Column`, meaning it will be treated
+onupdate" generator for the target :class:`_schema.Column`, meaning it will be treated
 as a default generating column when INSERT and UPDATE statements are generated,
 as well as that it will be fetched as a generating column when using the ORM.
 This includes that it will be part of the RETURNING clause of the database
 for databases which support RETURNING and the generated values are to be
 eagerly fetched.
 
-.. note:: A :class:`.Column` that is defined with the :class:`.Computed`
+.. note:: A :class:`_schema.Column` that is defined with the :class:`.Computed`
    construct may not store any value outside of that which the server applies
    to it;  SQLAlchemy's behavior when a value is passed for such a column
    to be written in INSERT or UPDATE is currently that the value will be
diff --git a/doc/build/core/dml.rst b/doc/build/core/dml.rst
index d116b67a5..7da8fb66c 100644
--- a/doc/build/core/dml.rst
+++ b/doc/build/core/dml.rst
@@ -2,7 +2,7 @@ Insert, Updates, Deletes
 ========================
 
 INSERT, UPDATE and DELETE statements build on a hierarchy starting
-with :class:`.UpdateBase`.   The :class:`~.sql.expression.Insert` and :class:`.Update`
+with :class:`.UpdateBase`.   The :class:`_expression.Insert` and :class:`_expression.Update`
 constructs build on the intermediary :class:`.ValuesBase`.
 
 .. currentmodule:: sqlalchemy.sql.expression
diff --git a/doc/build/core/engines.rst b/doc/build/core/engines.rst
index 643a06a98..f2e0beff6 100644
--- a/doc/build/core/engines.rst
+++ b/doc/build/core/engines.rst
@@ -4,7 +4,7 @@
 Engine Configuration
 ====================
 
-The :class:`.Engine` is the starting point for any SQLAlchemy application. It's
+The :class:`_engine.Engine` is the starting point for any SQLAlchemy application. It's
 "home base" for the actual database and its :term:`DBAPI`, delivered to the SQLAlchemy
 application through a connection pool and a :class:`.Dialect`, which describes how
 to talk to a specific kind of database/DBAPI combination.
@@ -13,8 +13,8 @@ The general structure can be illustrated as follows:
 
 .. image:: sqla_engine_arch.png
 
-Where above, an :class:`.Engine` references both a
-:class:`.Dialect` and a :class:`.Pool`,
+Where above, an :class:`_engine.Engine` references both a
+:class:`.Dialect` and a :class:`_pool.Pool`,
 which together interpret the DBAPI's module functions as well as the behavior
 of the database.
 
@@ -25,18 +25,18 @@ Creating an engine is just a matter of issuing a single call,
     engine = create_engine('postgresql://scott:tiger@localhost:5432/mydatabase')
 
 The above engine creates a :class:`.Dialect` object tailored towards
-PostgreSQL, as well as a :class:`.Pool` object which will establish a DBAPI
+PostgreSQL, as well as a :class:`_pool.Pool` object which will establish a DBAPI
 connection at ``localhost:5432`` when a connection request is first received.
-Note that the :class:`.Engine` and its underlying :class:`.Pool` do **not**
-establish the first actual DBAPI connection until the :meth:`.Engine.connect`
+Note that the :class:`_engine.Engine` and its underlying :class:`_pool.Pool` do **not**
+establish the first actual DBAPI connection until the :meth:`_engine.Engine.connect`
 method is called, or an operation which is dependent on this method such as
-:meth:`.Engine.execute` is invoked. In this way, :class:`.Engine` and
-:class:`.Pool` can be said to have a *lazy initialization* behavior.
+:meth:`_engine.Engine.execute` is invoked. In this way, :class:`_engine.Engine` and
+:class:`_pool.Pool` can be said to have a *lazy initialization* behavior.
 
-The :class:`.Engine`, once created, can either be used directly to interact with the database,
+The :class:`_engine.Engine`, once created, can either be used directly to interact with the database,
 or can be passed to a :class:`.Session` object to work with the ORM.   This section
-covers the details of configuring an :class:`.Engine`.   The next section, :ref:`connections_toplevel`,
-will detail the usage API of the :class:`.Engine` and similar, typically for non-ORM
+covers the details of configuring an :class:`_engine.Engine`.   The next section, :ref:`connections_toplevel`,
+will detail the usage API of the :class:`_engine.Engine` and similar, typically for non-ORM
 applications.
 
 .. _supported_dbapis:
@@ -55,7 +55,7 @@ See the section :ref:`dialect_toplevel` for information on the various backends
 Database Urls
 =============
 
-The :func:`.create_engine` function produces an :class:`.Engine` object based
+The :func:`.create_engine` function produces an :class:`_engine.Engine` object based
 on a URL.  These URLs follow `RFC-1738
 <http://rfc.net/rfc1738.html>`_, and usually can include username, password,
 hostname, database name as well as optional keyword arguments for additional configuration.
@@ -203,15 +203,15 @@ Engine Creation API
 Pooling
 =======
 
-The :class:`.Engine` will ask the connection pool for a
+The :class:`_engine.Engine` will ask the connection pool for a
 connection when the ``connect()`` or ``execute()`` methods are called. The
 default connection pool, :class:`~.QueuePool`, will open connections to the
 database on an as-needed basis. As concurrent statements are executed,
 :class:`.QueuePool` will grow its pool of connections to a
 default size of five, and will allow a default "overflow" of ten. Since the
-:class:`.Engine` is essentially "home base" for the
+:class:`_engine.Engine` is essentially "home base" for the
 connection pool, it follows that you should keep a single
-:class:`.Engine` per database established within an
+:class:`_engine.Engine` per database established within an
 application, rather than creating a new one for each connection.
 
 .. note::
@@ -329,13 +329,13 @@ string. To set this to a specific name, use the "logging_name" and
 
 .. note::
 
-   The SQLAlchemy :class:`.Engine` conserves Python function call overhead
+   The SQLAlchemy :class:`_engine.Engine` conserves Python function call overhead
    by only emitting log statements when the current logging level is detected
    as ``logging.INFO`` or ``logging.DEBUG``.  It only checks this level when
    a new connection is procured from the connection pool.  Therefore when
    changing the logging configuration for an already-running application, any
-   :class:`.Connection` that's currently active, or more commonly a
+   :class:`_engine.Connection` that's currently active, or more commonly a
    :class:`~.orm.session.Session` object that's active in a transaction, won't log any
-   SQL according to the new configuration until a new :class:`.Connection`
+   SQL according to the new configuration until a new :class:`_engine.Connection`
    is procured (in the case of :class:`~.orm.session.Session`, this is
    after the current transaction ends and a new one begins).
diff --git a/doc/build/core/event.rst b/doc/build/core/event.rst
index 6e53ae3b9..29f090a7b 100644
--- a/doc/build/core/event.rst
+++ b/doc/build/core/event.rst
@@ -19,7 +19,7 @@ instructions regarding secondary event targets based on the given target.
 
 The name of an event and the argument signature of a corresponding listener function is derived from
 a class bound specification method, which exists bound to a marker class that's described in the documentation.
-For example, the documentation for :meth:`.PoolEvents.connect` indicates that the event name is ``"connect"``
+For example, the documentation for :meth:`_events.PoolEvents.connect` indicates that the event name is ``"connect"``
 and that a user-defined listener function should receive two positional arguments::
 
     from sqlalchemy.event import listen
@@ -43,7 +43,7 @@ Named Argument Styles
 ---------------------
 
 There are some varieties of argument styles which can be accepted by listener
-functions.  Taking the example of :meth:`.PoolEvents.connect`, this function
+functions.  Taking the example of :meth:`_events.PoolEvents.connect`, this function
 is documented as receiving ``dbapi_connection`` and ``connection_record`` arguments.
 We can opt to receive these arguments by name, by establishing a listener function
 that accepts ``**keyword`` arguments, by passing ``named=True`` to either
@@ -84,7 +84,7 @@ The :func:`.listen` function is very flexible regarding targets.  It
 generally accepts classes, instances of those classes, and related
 classes or objects from which the appropriate target can be derived.
 For example, the above mentioned ``"connect"`` event accepts
-:class:`.Engine` classes and objects as well as :class:`.Pool` classes
+:class:`_engine.Engine` classes and objects as well as :class:`_pool.Pool` classes
 and objects::
 
     from sqlalchemy.event import listen
diff --git a/doc/build/core/inspection.rst b/doc/build/core/inspection.rst
index 01343102d..eab128842 100644
--- a/doc/build/core/inspection.rst
+++ b/doc/build/core/inspection.rst
@@ -14,11 +14,11 @@ Available Inspection Targets
 
 Below is a listing of many of the most common inspection targets.
 
-* :class:`.Connectable` (i.e. :class:`.Engine`,
-  :class:`.Connection`) - returns an :class:`.Inspector` object.
-* :class:`.ClauseElement` - all SQL expression components, including
-  :class:`.Table`, :class:`.Column`, serve as their own inspection objects,
-  meaning any of these objects passed to :func:`.inspect` return themselves.
+* :class:`.Connectable` (i.e. :class:`_engine.Engine`,
+  :class:`_engine.Connection`) - returns an :class:`_reflection.Inspector` object.
+* :class:`_expression.ClauseElement` - all SQL expression components, including
+  :class:`_schema.Table`, :class:`_schema.Column`, serve as their own inspection objects,
+  meaning any of these objects passed to :func:`_sa.inspect` return themselves.
 * ``object`` - an object given will be checked by the ORM for a mapping -
   if so, an :class:`.InstanceState` is returned representing the mapped
   state of the object.  The :class:`.InstanceState` also provides access
@@ -26,8 +26,8 @@ Below is a listing of many of the most common inspection targets.
   as the per-flush "history" of any attribute via the :class:`.History`
   object.
 * ``type`` (i.e. a class) - a class given will be checked by the ORM for a
-  mapping - if so, a :class:`.Mapper` for that class is returned.
-* mapped attribute - passing a mapped attribute to :func:`.inspect`, such
+  mapping - if so, a :class:`_orm.Mapper` for that class is returned.
+* mapped attribute - passing a mapped attribute to :func:`_sa.inspect`, such
   as ``inspect(MyClass.some_attribute)``, returns a :class:`.QueryableAttribute`
   object, which is the :term:`descriptor` associated with a mapped class.
   This descriptor refers to a :class:`.MapperProperty`, which is usually
diff --git a/doc/build/core/metadata.rst b/doc/build/core/metadata.rst
index c5865ae27..22bad5537 100644
--- a/doc/build/core/metadata.rst
+++ b/doc/build/core/metadata.rst
@@ -10,8 +10,8 @@ Describing Databases with MetaData
 
 .. module:: sqlalchemy.schema
 
-This section discusses the fundamental :class:`.Table`, :class:`.Column`
-and :class:`.MetaData` objects.
+This section discusses the fundamental :class:`_schema.Table`, :class:`_schema.Column`
+and :class:`_schema.MetaData` objects.
 
 A collection of metadata entities is stored in an object aptly named
 :class:`~sqlalchemy.schema.MetaData`::
@@ -237,8 +237,8 @@ While SQLAlchemy directly supports emitting CREATE and DROP statements for
 schema constructs, the ability to alter those constructs, usually via the ALTER
 statement as well as other database-specific constructs, is outside of the
 scope of SQLAlchemy itself.  While it's easy enough to emit ALTER statements
-and similar by hand, such as by passing a :func:`.text` construct to
-:meth:`.Connection.execute` or by using the :class:`.DDL` construct, it's a
+and similar by hand, such as by passing a :func:`_expression.text` construct to
+:meth:`_engine.Connection.execute` or by using the :class:`.DDL` construct, it's a
 common practice to automate the maintenance of database schemas in relation to
 application code using schema migration tools.
 
@@ -303,15 +303,15 @@ Column, Table, MetaData API
 
 .. attribute:: sqlalchemy.schema.BLANK_SCHEMA
 
-    Symbol indicating that a :class:`.Table` or :class:`.Sequence`
+    Symbol indicating that a :class:`_schema.Table` or :class:`.Sequence`
     should have 'None' for its schema, even if the parent
-    :class:`.MetaData` has specified a schema.
+    :class:`_schema.MetaData` has specified a schema.
 
     .. seealso::
 
-        :paramref:`.MetaData.schema`
+        :paramref:`_schema.MetaData.schema`
 
-        :paramref:`.Table.schema`
+        :paramref:`_schema.Table.schema`
 
         :paramref:`.Sequence.schema`
 
diff --git a/doc/build/core/pooling.rst b/doc/build/core/pooling.rst
index a4e01fcae..572b18f26 100644
--- a/doc/build/core/pooling.rst
+++ b/doc/build/core/pooling.rst
@@ -17,14 +17,14 @@ maintain a "pool" of active database connections in memory which are
 reused across requests.
 
 SQLAlchemy includes several connection pool implementations
-which integrate with the :class:`.Engine`.  They can also be used
+which integrate with the :class:`_engine.Engine`.  They can also be used
 directly for applications that want to add pooling to an otherwise
 plain DBAPI approach.
 
 Connection Pool Configuration
 -----------------------------
 
-The :class:`~.engine.Engine` returned by the
+The :class:`_engine.Engine` returned by the
 :func:`~sqlalchemy.create_engine` function in most cases has a :class:`.QueuePool`
 integrated, pre-configured with reasonable pooling defaults.  If
 you're reading this section only to learn how to enable pooling - congratulations!
@@ -80,7 +80,7 @@ Disabling pooling using :class:`.NullPool`::
 Using a Custom Connection Function
 ----------------------------------
 
-All :class:`.Pool` classes accept an argument ``creator`` which is
+All :class:`_pool.Pool` classes accept an argument ``creator`` which is
 a callable that creates a new connection.  :func:`.create_engine`
 accepts this function to pass onto the pool via an argument of
 the same name::
@@ -96,7 +96,7 @@ the same name::
     engine = create_engine('postgresql+psycopg2://', creator=getconn)
 
 For most "initialize on connection" routines, it's more convenient
-to use the :class:`.PoolEvents` event hooks, so that the usual URL argument to
+to use the :class:`_events.PoolEvents` event hooks, so that the usual URL argument to
 :func:`.create_engine` is still usable.  ``creator`` is there as
 a last resort for when a DBAPI has some form of ``connect``
 that is not at all supported by SQLAlchemy.
@@ -104,7 +104,7 @@ that is not at all supported by SQLAlchemy.
 Constructing a Pool
 -------------------
 
-To use a :class:`.Pool` by itself, the ``creator`` function is
+To use a :class:`_pool.Pool` by itself, the ``creator`` function is
 the only argument that's required and is passed first, followed
 by any additional options::
 
@@ -117,7 +117,7 @@ by any additional options::
 
     mypool = pool.QueuePool(getconn, max_overflow=10, pool_size=5)
 
-DBAPI connections can then be procured from the pool using the :meth:`.Pool.connect`
+DBAPI connections can then be procured from the pool using the :meth:`_pool.Pool.connect`
 function.  The return value of this method is a DBAPI connection that's contained
 within a transparent proxy::
 
@@ -147,9 +147,9 @@ existing transaction on the connection is removed, not only ensuring
 that no existing state remains on next usage, but also so that table
 and row locks are released as well as that any isolated data snapshots
 are removed.   This behavior can be disabled using the ``reset_on_return``
-option of :class:`.Pool`.
+option of :class:`_pool.Pool`.
 
-A particular pre-created :class:`.Pool` can be shared with one or more
+A particular pre-created :class:`_pool.Pool` can be shared with one or more
 engines by passing it to the ``pool`` argument of :func:`.create_engine`::
 
     e = create_engine('postgresql://', pool=mypool)
@@ -159,7 +159,7 @@ Pool Events
 
 Connection pools support an event interface that allows hooks to execute
 upon first connect, upon each new connection, and upon checkout and
-checkin of connections.   See :class:`.PoolEvents` for details.
+checkin of connections.   See :class:`_events.PoolEvents` for details.
 
 .. _pool_disconnects:
 
@@ -193,7 +193,7 @@ It is critical to note that the pre-ping approach **does not accommodate for
 connections dropped in the middle of transactions or other SQL operations**.
 If the database becomes unavailable while a transaction is in progress, the
 transaction will be lost and the database error will be raised.   While
-the :class:`.Connection` object will detect a "disconnect" situation and
+the :class:`_engine.Connection` object will detect a "disconnect" situation and
 recycle the connection as well as invalidate the rest of the connection pool
 when this condition occurs,
 the individual operation where the exception was raised will be lost, and it's
@@ -201,7 +201,7 @@ up to the application to either abandon
 the operation, or retry the whole transaction again.
 
 Pessimistic testing of connections upon checkout is achievable by
-using the :paramref:`.Pool.pre_ping` argument, available from :func:`.create_engine`
+using the :paramref:`_pool.Pool.pre_ping` argument, available from :func:`.create_engine`
 via the :paramref:`.create_engine.pool_pre_ping` argument::
 
     engine = create_engine("mysql+pymysql://user:pw@host/db", pool_pre_ping=True)
@@ -225,7 +225,7 @@ to three times before giving up, propagating the database error last received.
     Python latency.   As such, this statement is **not logged in the SQL
     echo output**, and will not show up in SQLAlchemy's engine logging.
 
-.. versionadded:: 1.2 Added "pre-ping" capability to the :class:`.Pool`
+.. versionadded:: 1.2 Added "pre-ping" capability to the :class:`_pool.Pool`
    class.
 
 Custom / Legacy Pessimistic Ping
@@ -281,9 +281,9 @@ behaviors are needed::
 
 The above recipe has the advantage that we are making use of SQLAlchemy's
 facilities for detecting those DBAPI exceptions that are known to indicate
-a "disconnect" situation, as well as the :class:`.Engine` object's ability
+a "disconnect" situation, as well as the :class:`_engine.Engine` object's ability
 to correctly invalidate the current connection pool when this condition
-occurs and allowing the current :class:`.Connection` to re-validate onto
+occurs and allowing the current :class:`_engine.Connection` to re-validate onto
 a new DBAPI connection.
 
 
@@ -296,13 +296,13 @@ a transaction, the other approach to dealing with stale / closed connections is
 to let SQLAlchemy handle disconnects as  they occur, at which point all
 connections in the pool are invalidated, meaning they are assumed to be
 stale and will be refreshed upon next checkout.  This behavior assumes the
-:class:`.Pool` is used in conjunction with a :class:`.Engine`.
-The :class:`.Engine` has logic which can detect
+:class:`_pool.Pool` is used in conjunction with a :class:`_engine.Engine`.
+The :class:`_engine.Engine` has logic which can detect
 disconnection events and refresh the pool automatically.
 
-When the :class:`.Connection` attempts to use a DBAPI connection, and an
+When the :class:`_engine.Connection` attempts to use a DBAPI connection, and an
 exception is raised that corresponds to a "disconnect" event, the connection
-is invalidated. The :class:`.Connection` then calls the :meth:`.Pool.recreate`
+is invalidated. The :class:`_engine.Connection` then calls the :meth:`_pool.Pool.recreate`
 method, effectively invalidating all connections not currently checked out so
 that they are replaced with new ones upon next checkout.  This flow is
 illustrated by the code example below::
@@ -351,7 +351,7 @@ period of time::
 Above, any DBAPI connection that has been open for more than one hour will be invalidated and replaced,
 upon next checkout.   Note that the invalidation **only** occurs during checkout - not on
 any connections that are held in a checked out state.     ``pool_recycle`` is a function
-of the :class:`.Pool` itself, independent of whether or not an :class:`.Engine` is in use.
+of the :class:`_pool.Pool` itself, independent of whether or not an :class:`_engine.Engine` is in use.
 
 
 .. _pool_connection_invalidation:
@@ -359,7 +359,7 @@ of the :class:`.Pool` itself, independent of whether or not an :class:`.Engine`
 More on Invalidation
 ^^^^^^^^^^^^^^^^^^^^
 
-The :class:`.Pool` provides "connection invalidation" services which allow
+The :class:`_pool.Pool` provides "connection invalidation" services which allow
 both explicit invalidation of a connection as well as automatic invalidation
 in response to conditions that are determined to render a connection unusable.
 
@@ -368,7 +368,7 @@ pool and discarded.  The ``.close()`` method is called on this connection
 if it is not clear that the connection itself might not be closed, however
 if this method fails, the exception is logged but the operation still proceeds.
 
-When using a :class:`.Engine`, the :meth:`.Connection.invalidate` method is
+When using a :class:`_engine.Engine`, the :meth:`_engine.Connection.invalidate` method is
 the usual entrypoint to explicit invalidation.   Other conditions by which
 a DBAPI connection might be invalidated include:
 
@@ -389,11 +389,11 @@ a DBAPI connection might be invalidated include:
   A final attempt at calling ``.close()`` on the connection will be made,
   and it is then discarded.
 
-* When a listener implementing :meth:`.PoolEvents.checkout` raises the
+* When a listener implementing :meth:`_events.PoolEvents.checkout` raises the
   :class:`~sqlalchemy.exc.DisconnectionError` exception, indicating that the connection
   won't be usable and a new connection attempt needs to be made.
 
-All invalidations which occur will invoke the :meth:`.PoolEvents.invalidate`
+All invalidations which occur will invoke the :meth:`_events.PoolEvents.invalidate`
 event.
 
 .. _pool_use_lifo:
@@ -436,7 +436,7 @@ Using Connection Pools with Multiprocessing
 -------------------------------------------
 
 It's critical that when using a connection pool, and by extension when
-using an :class:`.Engine` created via :func:`.create_engine`, that
+using an :class:`_engine.Engine` created via :func:`.create_engine`, that
 the pooled connections **are not shared to a forked process**.  TCP connections
 are represented as file descriptors, which usually work across process
 boundaries, meaning this will cause concurrent access to the file descriptor
@@ -444,8 +444,8 @@ on behalf of two or more entirely independent Python interpreter states.
 
 There are two approaches to dealing with this.
 
-The first is, either create a new :class:`.Engine` within the child
-process, or upon an existing :class:`.Engine`, call :meth:`.Engine.dispose`
+The first is, either create a new :class:`_engine.Engine` within the child
+process, or upon an existing :class:`_engine.Engine`, call :meth:`_engine.Engine.dispose`
 before the child process uses any connections.  This will remove all existing
 connections from the pool so that it makes all new ones.  Below is
 a simple version using ``multiprocessing.Process``, but this idea
@@ -461,7 +461,7 @@ should be adapted to the style of forking in use::
 
     p = Process(target=run_in_process)
 
-The next approach is to instrument the :class:`.Pool` itself with events
+The next approach is to instrument the :class:`_pool.Pool` itself with events
 so that connections are automatically invalidated in the subprocess.
 This is a little more magical but probably more foolproof::
 
diff --git a/doc/build/core/reflection.rst b/doc/build/core/reflection.rst
index 1848c044e..c320478a0 100644
--- a/doc/build/core/reflection.rst
+++ b/doc/build/core/reflection.rst
@@ -143,27 +143,27 @@ database is also available. This is known as the "Inspector"::
 Limitations of Reflection
 -------------------------
 
-It's important to note that the reflection process recreates :class:`.Table`
+It's important to note that the reflection process recreates :class:`_schema.Table`
 metadata using only information which is represented in the relational database.
 This process by definition cannot restore aspects of a schema that aren't
 actually stored in the database.   State which is not available from reflection
 includes but is not limited to:
 
 * Client side defaults, either Python functions or SQL expressions defined using
-  the ``default`` keyword of :class:`.Column` (note this is separate from ``server_default``,
+  the ``default`` keyword of :class:`_schema.Column` (note this is separate from ``server_default``,
   which specifically is what's available via reflection).
 
 * Column information, e.g. data that might have been placed into the
-  :attr:`.Column.info` dictionary
+  :attr:`_schema.Column.info` dictionary
 
-* The value of the ``.quote`` setting for :class:`.Column` or :class:`.Table`
+* The value of the ``.quote`` setting for :class:`_schema.Column` or :class:`_schema.Table`
 
-* The association of a particular :class:`.Sequence` with a given :class:`.Column`
+* The association of a particular :class:`.Sequence` with a given :class:`_schema.Column`
 
 The relational database also in many cases reports on table metadata in a
-different format than what was specified in SQLAlchemy.   The :class:`.Table`
+different format than what was specified in SQLAlchemy.   The :class:`_schema.Table`
 objects returned from reflection cannot be always relied upon to produce the identical
-DDL as the original Python-defined :class:`.Table` objects.   Areas where
+DDL as the original Python-defined :class:`_schema.Table` objects.   Areas where
 this occurs includes server defaults, column-associated sequences and various
 idiosyncrasies regarding constraints and datatypes.   Server side defaults may
 be returned with cast directives (typically PostgreSQL will include a ``::<type>``
diff --git a/doc/build/core/selectable.rst b/doc/build/core/selectable.rst
index 2f69c0200..72436d75d 100644
--- a/doc/build/core/selectable.rst
+++ b/doc/build/core/selectable.rst
@@ -2,10 +2,10 @@ Selectables, Tables, FROM objects
 =================================
 
 The term "selectable" refers to any object that rows can be selected from;
-in SQLAlchemy, these objects descend from :class:`.FromClause` and their
-distinguishing feature is their :attr:`.FromClause.c` attribute, which is
+in SQLAlchemy, these objects descend from :class:`_expression.FromClause` and their
+distinguishing feature is their :attr:`_expression.FromClause.c` attribute, which is
 a namespace of all the columns contained within the FROM clause (these
-elements are themselves :class:`.ColumnElement` subclasses).
+elements are themselves :class:`_expression.ColumnElement` subclasses).
 
 .. currentmodule:: sqlalchemy.sql.expression
 
diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst
index 720aadbe7..0973e487b 100644
--- a/doc/build/core/tutorial.rst
+++ b/doc/build/core/tutorial.rst
@@ -78,7 +78,7 @@ the SQL behind a popup window so it doesn't get in our way; just click the
 "SQL" links to see what's being generated.
 
 The return value of :func:`.create_engine` is an instance of
-:class:`.Engine`, and it represents the core interface to the
+:class:`_engine.Engine`, and it represents the core interface to the
 database, adapted through a :term:`dialect` that handles the details
 of the database and :term:`DBAPI` in use.  In this case the SQLite
 dialect will interpret instructions to the Python built-in ``sqlite3``
@@ -86,12 +86,12 @@ module.
 
 .. sidebar:: Lazy Connecting
 
-    The :class:`.Engine`, when first returned by :func:`.create_engine`,
+    The :class:`_engine.Engine`, when first returned by :func:`.create_engine`,
     has not actually tried to connect to the database yet; that happens
     only the first time it is asked to perform a task against the database.
 
-The first time a method like :meth:`.Engine.execute` or :meth:`.Engine.connect`
-is called, the :class:`.Engine` establishes a real :term:`DBAPI` connection to the
+The first time a method like :meth:`_engine.Engine.execute` or :meth:`_engine.Engine.connect`
+is called, the :class:`_engine.Engine` establishes a real :term:`DBAPI` connection to the
 database, which is then used to emit the SQL.
 
 .. seealso::
@@ -200,7 +200,7 @@ each table first before creating, so it's safe to call multiple times:
            Column('nickname', String(50))
         )
 
-    We include this more verbose :class:`~.schema.Table` construct separately
+    We include this more verbose :class:`_schema.Table` construct separately
     to highlight the difference between a minimal construct geared primarily
     towards in-Python usage only, versus one that will be used to emit CREATE
     TABLE statements on a particular set of backends with more stringent
@@ -332,10 +332,10 @@ and use it in the "normal" way:
     {stop}<sqlalchemy.engine.result.ResultProxy object at 0x...>
 
 Above, because we specified all three columns in the ``execute()`` method,
-the compiled :class:`~.expression.Insert` included all three
-columns. The :class:`~.expression.Insert` statement is compiled
+the compiled :class:`_expression.Insert` included all three
+columns. The :class:`_expression.Insert` statement is compiled
 at execution time based on the parameters we specified; if we specified fewer
-parameters, the :class:`~.expression.Insert` would have fewer
+parameters, the :class:`_expression.Insert` would have fewer
 entries in its VALUES clause.
 
 To issue many inserts using DBAPI's ``executemany()`` method, we can send in a
@@ -366,7 +366,7 @@ assumed that all subsequent argument dictionaries are compatible with that
 statement.
 
 The "executemany" style of invocation is available for each of the
-:func:`~.sql.expression.insert`, :func:`.update` and :func:`.delete` constructs.
+:func:`_expression.insert`, :func:`_expression.update` and :func:`_expression.delete` constructs.
 
 
 .. _coretutorial_selecting:
@@ -377,7 +377,7 @@ Selecting
 We began with inserts just so that our test database had some data in it. The
 more interesting part of the data is selecting it! We'll cover UPDATE and
 DELETE statements later. The primary construct used to generate SELECT
-statements is the :func:`~.sql.expression.select` function:
+statements is the :func:`_expression.select` function:
 
 .. sourcecode:: pycon+sql
 
@@ -388,7 +388,7 @@ statements is the :func:`~.sql.expression.select` function:
     FROM users
     ()
 
-Above, we issued a basic :func:`~.sql.expression.select` call, placing the ``users`` table
+Above, we issued a basic :func:`_expression.select` call, placing the ``users`` table
 within the COLUMNS clause of the select, and then executing. SQLAlchemy
 expanded the ``users`` table into the set of each of its columns, and also
 generated a FROM clause for us. The result returned is again a
@@ -482,7 +482,7 @@ may be used as well:
 
 A more specialized method of column access is to use the SQL construct that
 directly corresponds to a particular column as the mapping key; in this
-example, it means we would use the  :class:`.Column` objects selected in our
+example, it means we would use the  :class:`_schema.Column` objects selected in our
 SELECT directly as keys in conjunction with the :attr:`.Row._mapping`
 collection:
 
@@ -537,9 +537,9 @@ the ``c`` attribute of the :class:`~sqlalchemy.schema.Table` object:
 
 Lets observe something interesting about the FROM clause. Whereas the
 generated statement contains two distinct sections, a "SELECT columns" part
-and a "FROM table" part, our :func:`~.sql.expression.select` construct only has a list
+and a "FROM table" part, our :func:`_expression.select` construct only has a list
 containing columns. How does this work ? Let's try putting *two* tables into
-our :func:`~.sql.expression.select` statement:
+our :func:`_expression.select` statement:
 
 .. sourcecode:: pycon+sql
 
@@ -561,7 +561,7 @@ It placed **both** tables into the FROM clause. But also, it made a real mess.
 Those who are familiar with SQL joins know that this is a **Cartesian
 product**; each row from the ``users`` table is produced against each row from
 the ``addresses`` table. So to put some sanity into this statement, we need a
-WHERE clause.  We do that using :meth:`.Select.where`:
+WHERE clause.  We do that using :meth:`_expression.Select.where`:
 
 .. sourcecode:: pycon+sql
 
@@ -578,7 +578,7 @@ WHERE clause.  We do that using :meth:`.Select.where`:
     (2, u'wendy', u'Wendy Williams', 3, 2, u'www@www.org')
     (2, u'wendy', u'Wendy Williams', 4, 2, u'wendy@aol.com')
 
-So that looks a lot better, we added an expression to our :func:`~.sql.expression.select`
+So that looks a lot better, we added an expression to our :func:`_expression.select`
 which had the effect of adding ``WHERE users.id = addresses.user_id`` to our
 statement, and our results were managed down so that the join of ``users`` and
 ``addresses`` rows made sense. But let's look at that expression? It's using
@@ -600,11 +600,11 @@ Wow, surprise ! This is neither a ``True`` nor a ``False``. Well what is it ?
     'users.id = addresses.user_id'
 
 As you can see, the ``==`` operator is producing an object that is very much
-like the :class:`~.expression.Insert` and :func:`~.sql.expression.select`
+like the :class:`_expression.Insert` and :func:`_expression.select`
 objects we've made so far, thanks to Python's ``__eq__()`` builtin; you call
 ``str()`` on it and it produces SQL. By now, one can see that everything we
 are working with is ultimately the same type of object. SQLAlchemy terms the
-base class of all of these expressions as :class:`~.expression.ColumnElement`.
+base class of all of these expressions as :class:`_expression.ColumnElement`.
 
 Operators
 =========
@@ -626,7 +626,7 @@ we get a bind parameter:
     users.id = :id_1
 
 The ``7`` literal is embedded the resulting
-:class:`~.expression.ColumnElement`; we can use the same trick
+:class:`_expression.ColumnElement`; we can use the same trick
 we did with the :class:`~sqlalchemy.sql.expression.Insert` object to see it:
 
 .. sourcecode:: pycon+sql
@@ -728,7 +728,7 @@ Conjunctions
 ============
 
 
-We'd like to show off some of our operators inside of :func:`~.sql.expression.select`
+We'd like to show off some of our operators inside of :func:`_expression.select`
 constructs. But we need to lump them together a little more, so let's first
 introduce some conjunctions. Conjunctions are those little words like AND and
 OR that put things together. We'll also hit upon NOT. :func:`.and_`, :func:`.or_`,
@@ -776,9 +776,9 @@ So with all of this vocabulary, let's select all users who have an email
 address at AOL or MSN, whose name starts with a letter between "m" and "z",
 and we'll also generate a column containing their full name combined with
 their email address. We will add two new constructs to this statement,
-:meth:`~.ColumnOperators.between` and :meth:`~.ColumnElement.label`.
+:meth:`~.ColumnOperators.between` and :meth:`_expression.ColumnElement.label`.
 :meth:`~.ColumnOperators.between` produces a BETWEEN clause, and
-:meth:`~.ColumnElement.label` is used in a column expression to produce labels using the ``AS``
+:meth:`_expression.ColumnElement.label` is used in a column expression to produce labels using the ``AS``
 keyword; it's recommended when selecting from expressions that otherwise would
 not have a name:
 
@@ -811,7 +811,7 @@ clause, the where clause, and also some other elements which we haven't
 covered yet, which include ORDER BY, GROUP BY, and HAVING.
 
 A shortcut to using :func:`.and_` is to chain together multiple
-:meth:`~.Select.where` clauses.   The above can also be written as:
+:meth:`_expression.Select.where` clauses.   The above can also be written as:
 
 .. sourcecode:: pycon+sql
 
@@ -834,7 +834,7 @@ A shortcut to using :func:`.and_` is to chain together multiple
     (', ', 'm', 'z', '%@aol.com', '%@msn.com')
     [(u'Wendy Williams, wendy@aol.com',)]
 
-The way that we can build up a :func:`~.sql.expression.select` construct through successive
+The way that we can build up a :func:`_expression.select` construct through successive
 method calls is called :term:`method chaining`.
 
 .. _sqlexpression_text:
@@ -847,9 +847,9 @@ understands to be a textual SQL expression into a Python construct which
 groups components together in a programmatic style can be hard. That's why
 SQLAlchemy lets you just use strings, for those cases when the SQL
 is already known and there isn't a strong need for the statement to support
-dynamic features.  The :func:`~.expression.text` construct is used
+dynamic features.  The :func:`_expression.text` construct is used
 to compose a textual statement that is passed to the database mostly
-unchanged.  Below, we create a :func:`~.expression.text` object and execute it:
+unchanged.  Below, we create a :func:`_expression.text` object and execute it:
 
 .. sourcecode:: pycon+sql
 
@@ -870,16 +870,16 @@ unchanged.  Below, we create a :func:`~.expression.text` object and execute it:
     {stop}[(u'Wendy Williams, wendy@aol.com',)]
 
 Above, we can see that bound parameters are specified in
-:func:`~.expression.text` using the named colon format; this format is
+:func:`_expression.text` using the named colon format; this format is
 consistent regardless of database backend.  To send values in for the
-parameters, we passed them into the :meth:`~.Connection.execute` method
+parameters, we passed them into the :meth:`_engine.Connection.execute` method
 as additional arguments.
 
 Specifying Bound Parameter Behaviors
 ------------------------------------
 
-The :func:`~.expression.text` construct supports pre-established bound values
-using the :meth:`.TextClause.bindparams` method::
+The :func:`_expression.text` construct supports pre-established bound values
+using the :meth:`_expression.TextClause.bindparams` method::
 
     stmt = text("SELECT * FROM users WHERE users.name BETWEEN :x AND :y")
     stmt = stmt.bindparams(x="m", y="z")
@@ -894,7 +894,7 @@ or special SQL-side processing provided by the datatype.
 
 .. seealso::
 
-    :meth:`.TextClause.bindparams` - full method description
+    :meth:`_expression.TextClause.bindparams` - full method description
 
 .. _sqlexpression_text_columns:
 
@@ -902,7 +902,7 @@ Specifying Result-Column Behaviors
 ----------------------------------
 
 We may also specify information about the result columns using the
-:meth:`.TextClause.columns` method; this method can be used to specify
+:meth:`_expression.TextClause.columns` method; this method can be used to specify
 the return types, based on name::
 
     stmt = stmt.columns(id=Integer, name=String)
@@ -915,7 +915,7 @@ expressions to the SQL will be done positionally::
     stmt = text("SELECT id, name FROM users")
     stmt = stmt.columns(users.c.id, users.c.name)
 
-When we call the :meth:`.TextClause.columns` method, we get back a
+When we call the :meth:`_expression.TextClause.columns` method, we get back a
 :class:`.TextAsFrom` object that supports the full suite of
 :attr:`.TextAsFrom.c` and other "selectable" operations::
 
@@ -924,7 +924,7 @@ When we call the :meth:`.TextClause.columns` method, we get back a
     new_stmt = select([stmt.c.id, addresses.c.id]).\
         select_from(j).where(stmt.c.name == 'x')
 
-The positional form of :meth:`.TextClause.columns` is particularly useful
+The positional form of :meth:`_expression.TextClause.columns` is particularly useful
 when relating textual SQL to existing Core or ORM models, because we can use
 column expressions directly without worrying about name conflicts or other issues with the
 result column names in the textual SQL:
@@ -967,40 +967,40 @@ the ``id`` value::
     InvalidRequestError: Ambiguous column name 'id' in result set column descriptions
 
 It's important to note that while accessing columns from a result set using
-:class:`.Column` objects may seem unusual, it is in fact the only system
+:class:`_schema.Column` objects may seem unusual, it is in fact the only system
 used by the ORM, which occurs transparently beneath the facade of the
-:class:`~.orm.query.Query` object; in this way, the :meth:`.TextClause.columns` method
+:class:`~.orm.query.Query` object; in this way, the :meth:`_expression.TextClause.columns` method
 is typically very applicable to textual statements to be used in an ORM
 context.   The example at :ref:`orm_tutorial_literal_sql` illustrates
 a simple usage.
 
 .. versionadded:: 1.1
 
-    The :meth:`.TextClause.columns` method now accepts column expressions
+    The :meth:`_expression.TextClause.columns` method now accepts column expressions
     which will be matched positionally to a plain text SQL result set,
     eliminating the need for column names to match or even be unique in the
     SQL statement when matching table metadata or ORM models to textual SQL.
 
 .. seealso::
 
-    :meth:`.TextClause.columns` - full method description
+    :meth:`_expression.TextClause.columns` - full method description
 
     :ref:`orm_tutorial_literal_sql` - integrating ORM-level queries with
-    :func:`.text`
+    :func:`_expression.text`
 
 
 Using text() fragments inside bigger statements
 -----------------------------------------------
 
-:func:`~.expression.text` can also be used to produce fragments of SQL
+:func:`_expression.text` can also be used to produce fragments of SQL
 that can be freely within a
-:func:`~.expression.select` object, which accepts :func:`~.expression.text`
+:func:`_expression.select` object, which accepts :func:`_expression.text`
 objects as an argument for most of its builder functions.
-Below, we combine the usage of :func:`~.expression.text` within a
-:func:`~.sql.expression.select` object.  The :func:`~.expression.select` construct provides the "geometry"
-of the statement, and the :func:`~.expression.text` construct provides the
+Below, we combine the usage of :func:`_expression.text` within a
+:func:`_expression.select` object.  The :func:`_expression.select` construct provides the "geometry"
+of the statement, and the :func:`_expression.text` construct provides the
 textual content within this form.  We can build a statement without the
-need to refer to any pre-established :class:`.Table` metadata:
+need to refer to any pre-established :class:`_schema.Table` metadata:
 
 .. sourcecode:: pycon+sql
 
@@ -1025,30 +1025,29 @@ need to refer to any pre-established :class:`.Table` metadata:
     {stop}[(u'Wendy Williams, wendy@aol.com',)]
 
 .. versionchanged:: 1.0.0
-   The :func:`~.sql.expression.select` construct emits warnings when string SQL
-   fragments are coerced to :func:`.text`, and :func:`.text` should
+   The :func:`_expression.select` construct emits warnings when string SQL
+   fragments are coerced to :func:`_expression.text`, and :func:`_expression.text` should
    be used explicitly.  See :ref:`migration_2992` for background.
 
 
 
 .. _sqlexpression_literal_column:
 
-Using More Specific Text with :func:`.table`, :func:`.literal_column`, and :func:`.column`
--------------------------------------------------------------------------------------------
-
+Using More Specific Text with :func:`.table`, :func:`_expression.literal_column`, and :func:`_expression.column`
+-----------------------------------------------------------------------------------------------------------------
 We can move our level of structure back in the other direction too,
-by using :func:`~.expression.column`, :func:`~.expression.literal_column`,
-and :func:`~.expression.table` for some of the
+by using :func:`_expression.column`, :func:`_expression.literal_column`,
+and :func:`_expression.table` for some of the
 key elements of our statement.   Using these constructs, we can get
-some more expression capabilities than if we used :func:`~.expression.text`
+some more expression capabilities than if we used :func:`_expression.text`
 directly, as they provide to the Core more information about how the strings
 they store are to be used, but still without the need to get into full
-:class:`.Table` based metadata.  Below, we also specify the :class:`.String`
-datatype for two of the key :func:`~.expression.literal_column` objects,
+:class:`_schema.Table` based metadata.  Below, we also specify the :class:`.String`
+datatype for two of the key :func:`_expression.literal_column` objects,
 so that the string-specific concatenation operator becomes available.
-We also use :func:`~.expression.literal_column` in order to use table-qualified
+We also use :func:`_expression.literal_column` in order to use table-qualified
 expressions, e.g. ``users.fullname``, that will be rendered as is;
-using :func:`~.expression.column` implies an individual column name that may
+using :func:`_expression.column` implies an individual column name that may
 be quoted:
 
 .. sourcecode:: pycon+sql
@@ -1086,8 +1085,8 @@ One place where we sometimes want to use a string as a shortcut is when
 our statement has some labeled column element that we want to refer to in
 a place such as the "ORDER BY" or "GROUP BY" clause; other candidates include
 fields within an "OVER" or "DISTINCT" clause.  If we have such a label
-in our :func:`~.sql.expression.select` construct, we can refer to it directly by passing the
-string straight into :meth:`.select.order_by` or :meth:`.select.group_by`,
+in our :func:`_expression.select` construct, we can refer to it directly by passing the
+string straight into :meth:`_expression.select.order_by` or :meth:`_expression.select.group_by`,
 among others.  This will refer to the named label and also prevent the
 expression from being rendered twice.  Label names that resolve to columns
 are rendered fully:
@@ -1124,11 +1123,11 @@ name:
     {stop}[(1, 2), (2, 2)]
 
 Note that the string feature here is very much tailored to when we have
-already used the :meth:`~.ColumnElement.label` method to create a
+already used the :meth:`_expression.ColumnElement.label` method to create a
 specifically-named label.  In other cases, we always want to refer to the
-:class:`.ColumnElement` object directly so that the expression system can
+:class:`_expression.ColumnElement` object directly so that the expression system can
 make the most effective choices for rendering.  Below, we illustrate how using
-the :class:`.ColumnElement` eliminates ambiguity when we want to order
+the :class:`_expression.ColumnElement` eliminates ambiguity when we want to order
 by a column name that appears more than once:
 
 .. sourcecode:: pycon+sql
@@ -1162,11 +1161,11 @@ FROM clause multiple times. In the case of a SELECT statement, it provides a
 parent name for the columns represented by the statement, allowing them to be
 referenced relative to this name.
 
-In SQLAlchemy, any :class:`.Table` or other :class:`.FromClause` based
-selectable can be turned into an alias using :meth:`.FromClause.alias` method,
-which produces an :class:`.Alias` construct.   :class:`.Alias` is a
-:class:`.FromClause` object that refers to a mapping of :class:`.Column`
-objects via its :attr:`.FromClause.c` collection, and can be used within the
+In SQLAlchemy, any :class:`_schema.Table` or other :class:`_expression.FromClause` based
+selectable can be turned into an alias using :meth:`_expression.FromClause.alias` method,
+which produces an :class:`_expression.Alias` construct.   :class:`_expression.Alias` is a
+:class:`_expression.FromClause` object that refers to a mapping of :class:`_schema.Column`
+objects via its :attr:`_expression.FromClause.c` collection, and can be used within the
 FROM clause of any subsequent SELECT statement, by referring to its column
 elements in the columns or WHERE clause of the statement,  or through explicit
 placement in the FROM clause, either directly or within a join.
@@ -1174,8 +1173,8 @@ placement in the FROM clause, either directly or within a join.
 As an example, suppose we know that our user ``jack`` has two particular email
 addresses. How can we locate jack based on the combination of those two
 addresses?   To accomplish this, we'd use a join to the ``addresses`` table,
-once for each address.   We create two :class:`.Alias` constructs against
-``addresses``, and then use them both within a :func:`~.sql.expression.select` construct:
+once for each address.   We create two :class:`_expression.Alias` constructs against
+``addresses``, and then use them both within a :func:`_expression.select` construct:
 
 .. sourcecode:: pycon+sql
 
@@ -1198,7 +1197,7 @@ once for each address.   We create two :class:`.Alias` constructs against
     ('jack@msn.com', 'jack@yahoo.com')
     {stop}[(1, u'jack', u'Jack Jones')]
 
-Note that the :class:`.Alias` construct generated the names ``addresses_1`` and
+Note that the :class:`_expression.Alias` construct generated the names ``addresses_1`` and
 ``addresses_2`` in the final SQL result.  The generation of these names is determined
 by the position of the construct within the statement.   If we created a query using
 only the second ``a2`` alias, the name would come out as ``addresses_1``.  The
@@ -1206,22 +1205,22 @@ generation of the names is also *deterministic*, meaning the same SQLAlchemy
 statement construct will produce the identical SQL string each time it is
 rendered for a particular dialect.
 
-Since on the outside, we refer to the alias using the :class:`.Alias` construct
+Since on the outside, we refer to the alias using the :class:`_expression.Alias` construct
 itself, we don't need to be concerned about the generated name.  However, for
 the purposes of debugging, it can be specified by passing a string name
-to the :meth:`.FromClause.alias` method::
+to the :meth:`_expression.FromClause.alias` method::
 
     >>> a1 = addresses.alias('a1')
 
-SELECT-oriented constructs which extend from :class:`.SelectBase` may be turned
-into aliased subqueries using the :meth:`.SelectBase.subquery` method, which
+SELECT-oriented constructs which extend from :class:`_expression.SelectBase` may be turned
+into aliased subqueries using the :meth:`_expression.SelectBase.subquery` method, which
 produces a :class:`.Subquery` construct; for ease of use, there is also a
-:meth:`.SelectBase.alias` method that is synonymous with
-:class:`.SelectBase.subquery`.   Like  :class:`.Alias`, :class:`.Subquery` is
-also a :class:`.FromClause` object that may be part of any enclosing SELECT
-using the same techniques one would use for a :class:`.Alias`.
+:meth:`_expression.SelectBase.alias` method that is synonymous with
+:class:`_expression.SelectBase.subquery`.   Like  :class:`_expression.Alias`, :class:`.Subquery` is
+also a :class:`_expression.FromClause` object that may be part of any enclosing SELECT
+using the same techniques one would use for a :class:`_expression.Alias`.
 
-We can self-join the ``users`` table back to the :func:`~.sql.expression.select` we've created
+We can self-join the ``users`` table back to the :func:`_expression.select` we've created
 by making :class:`.Subquery` of the entire statement:
 
 .. sourcecode:: pycon+sql
@@ -1250,9 +1249,9 @@ Using Joins
 We're halfway along to being able to construct any SELECT expression. The next
 cornerstone of the SELECT is the JOIN expression. We've already been doing
 joins in our examples, by just placing two tables in either the columns clause
-or the where clause of the :func:`~.sql.expression.select` construct. But if we want to make a
-real "JOIN" or "OUTERJOIN" construct, we use the :meth:`~.FromClause.join` and
-:meth:`~.FromClause.outerjoin` methods, most commonly accessed from the left table in the
+or the where clause of the :func:`_expression.select` construct. But if we want to make a
+real "JOIN" or "OUTERJOIN" construct, we use the :meth:`_expression.FromClause.join` and
+:meth:`_expression.FromClause.outerjoin` methods, most commonly accessed from the left table in the
 join:
 
 .. sourcecode:: pycon+sql
@@ -1279,10 +1278,10 @@ username:
     ...  )
     users JOIN addresses ON addresses.email_address LIKE users.name || :name_1
 
-When we create a :func:`~.sql.expression.select` construct, SQLAlchemy looks around at the
+When we create a :func:`_expression.select` construct, SQLAlchemy looks around at the
 tables we've mentioned and then places them in the FROM clause of the
 statement. When we use JOINs however, we know what FROM clause we want, so
-here we make use of the :meth:`~.Select.select_from` method:
+here we make use of the :meth:`_expression.Select.select_from` method:
 
 .. sourcecode:: pycon+sql
 
@@ -1296,8 +1295,8 @@ here we make use of the :meth:`~.Select.select_from` method:
     ('%',)
     {stop}[(u'Jack Jones',), (u'Jack Jones',), (u'Wendy Williams',)]
 
-The :meth:`~.FromClause.outerjoin` method creates ``LEFT OUTER JOIN`` constructs,
-and is used in the same way as :meth:`~.FromClause.join`:
+The :meth:`_expression.FromClause.outerjoin` method creates ``LEFT OUTER JOIN`` constructs,
+and is used in the same way as :meth:`_expression.FromClause.join`:
 
 .. sourcecode:: pycon+sql
 
@@ -1324,11 +1323,11 @@ Oracle DBAs don't want their black magic being found out ;).
 
 .. seealso::
 
-    :func:`.expression.join`
+    :func:`_expression.join`
 
-    :func:`.expression.outerjoin`
+    :func:`_expression.outerjoin`
 
-    :class:`.Join`
+    :class:`_expression.Join`
 
 Everything Else
 ===============
@@ -1610,7 +1609,7 @@ another function :func:`.type_coerce` which is closely related to
 :func:`.cast`, in that it sets up a Python expression as having a specific SQL
 database type, but does not render the ``CAST`` keyword or datatype on the
 database side.    :func:`.type_coerce` is particularly important when dealing
-with the :class:`.types.JSON` datatype, which typically has an intricate
+with the :class:`_types.JSON` datatype, which typically has an intricate
 relationship with string-oriented datatypes on different platforms and
 may not even be an explicit datatype, such as on SQLite and MariaDB.
 Below, we use :func:`.type_coerce` to deliver a Python structure as a JSON
@@ -1632,7 +1631,7 @@ string into one of MySQL's JSON functions:
 
 Above, MySQL's ``JSON_EXTRACT`` SQL function was invoked
 because we used :func:`.type_coerce` to indicate that our Python dictionary
-should be treated as :class:`.types.JSON`.  The Python ``__getitem__``
+should be treated as :class:`_types.JSON`.  The Python ``__getitem__``
 operator, ``['some_key']`` in this case, became available as a result and
 allowed a ``JSON_EXTRACT`` path expression (not shown, however in this
 case it would ultimately be ``'$."some_key"'``) to be rendered.
@@ -1641,8 +1640,8 @@ Unions and Other Set Operations
 -------------------------------
 
 Unions come in two flavors, UNION and UNION ALL, which are available via
-module level functions :func:`~.expression.union` and
-:func:`~.expression.union_all`:
+module level functions :func:`_expression.union` and
+:func:`_expression.union_all`:
 
 .. sourcecode:: pycon+sql
 
@@ -1666,9 +1665,9 @@ module level functions :func:`~.expression.union` and
     {stop}[(1, 1, u'jack@yahoo.com')]
 
 Also available, though not supported on all databases, are
-:func:`~.expression.intersect`,
-:func:`~.expression.intersect_all`,
-:func:`~.expression.except_`, and :func:`~.expression.except_all`:
+:func:`_expression.intersect`,
+:func:`_expression.intersect_all`,
+:func:`_expression.except_`, and :func:`_expression.except_all`:
 
 .. sourcecode:: pycon+sql
 
@@ -1731,17 +1730,17 @@ want the "union" to be stated as a subquery:
 
 .. seealso::
 
-    :func:`.union`
+    :func:`_expression.union`
 
-    :func:`.union_all`
+    :func:`_expression.union_all`
 
-    :func:`.intersect`
+    :func:`_expression.intersect`
 
-    :func:`.intersect_all`
+    :func:`_expression.intersect_all`
 
     :func:`.except_`
 
-    :func:`.except_all`
+    :func:`_expression.except_all`
 
 Ordering Unions
 ^^^^^^^^^^^^^^^
@@ -1752,7 +1751,7 @@ whole result usually requires that an ORDER BY clause refer to column names but
 not specific tables.  As in the previous examples, we used
 ``.order_by(addresses.c.email_address)`` but SQLAlchemy rendered the ORDER BY
 without using the table name.    A generalized way to apply ORDER BY to a union
-is also to refer to the :attr:`.CompoundSelect.selected_columns` collection in
+is also to refer to the :attr:`_selectable.CompoundSelect.selected_columns` collection in
 order to access the column expressions which are synonymous with the columns
 selected from the first SELECT; the SQLAlchemy compiler will ensure these will
 be rendered without table names::
@@ -1783,9 +1782,9 @@ column.  It can then be used as a column expression.  A scalar select
 is often a :term:`correlated subquery`, which relies upon the enclosing
 SELECT statement in order to acquire at least one of its FROM clauses.
 
-The :func:`~.sql.expression.select` construct can be modified to act as a
-column expression by calling either the :meth:`~.SelectBase.scalar_subquery`
-or :meth:`~.SelectBase.label` method:
+The :func:`_expression.select` construct can be modified to act as a
+column expression by calling either the :meth:`_expression.SelectBase.scalar_subquery`
+or :meth:`_expression.SelectBase.label` method:
 
 .. sourcecode:: pycon+sql
 
@@ -1793,11 +1792,11 @@ or :meth:`~.SelectBase.label` method:
     ...             where(users.c.id == addresses.c.user_id).\
     ...             scalar_subquery()
 
-The above construct is now a :class:`~.expression.ScalarSelect` object,
+The above construct is now a :class:`_expression.ScalarSelect` object,
 which is an adapter around the original :class:`.~expression.Select`
-object; it participates within the :class:`~.expression.ColumnElement`
+object; it participates within the :class:`_expression.ColumnElement`
 family of expression constructs.  We can place this construct the same as any
-other column within another :func:`~.sql.expression.select`:
+other column within another :func:`_expression.select`:
 
 .. sourcecode:: pycon+sql
 
@@ -1810,7 +1809,7 @@ other column within another :func:`~.sql.expression.select`:
     {stop}[(u'jack', 2), (u'wendy', 2)]
 
 To apply a non-anonymous column name to our scalar select, we create
-it using :meth:`.SelectBase.label` instead:
+it using :meth:`_expression.SelectBase.label` instead:
 
 .. sourcecode:: pycon+sql
 
@@ -1827,9 +1826,9 @@ it using :meth:`.SelectBase.label` instead:
 
 .. seealso::
 
-    :meth:`.Select.scalar_subquery`
+    :meth:`_expression.Select.scalar_subquery`
 
-    :meth:`.Select.label`
+    :meth:`_expression.Select.label`
 
 .. _correlated_subqueries:
 
@@ -1862,7 +1861,7 @@ still have at least one FROM clause of its own.  For example:
 Auto-correlation will usually do what's expected, however it can also be controlled.
 For example, if we wanted a statement to correlate only to the ``addresses`` table
 but not the ``users`` table, even if both were present in the enclosing SELECT,
-we use the :meth:`~.Select.correlate` method to specify those FROM clauses that
+we use the :meth:`_expression.Select.correlate` method to specify those FROM clauses that
 may be correlated:
 
 .. sourcecode:: pycon+sql
@@ -1903,7 +1902,7 @@ as the argument:
     ('wendy',)
     {stop}[(u'wendy',)]
 
-We can also control correlation via exclusion, using the :meth:`.Select.correlate_except`
+We can also control correlation via exclusion, using the :meth:`_expression.Select.correlate_except`
 method.   Such as, we can write our SELECT for the ``users`` table
 by telling it to correlate all FROM clauses except for ``users``:
 
@@ -1954,7 +1953,7 @@ behavior around, allowing an expression such as:
 Where above, the right side of the JOIN contains a subquery that refers not
 just to the "books" table but also the "people" table, correlating
 to the left side of the JOIN.   SQLAlchemy Core supports a statement
-like the above using the :meth:`.Select.lateral` method as follows::
+like the above using the :meth:`_expression.Select.lateral` method as follows::
 
     >>> from sqlalchemy import table, column, select, true
     >>> people = table('people', column('people_id'), column('age'), column('name'))
@@ -1967,20 +1966,20 @@ like the above using the :meth:`.Select.lateral` method as follows::
     FROM books WHERE books.owner_id = people.people_id)
     AS book_subq ON true
 
-Above, we can see that the :meth:`.Select.lateral` method acts a lot like
-the :meth:`.Select.alias` method, including that we can specify an optional
-name.  However the construct is the :class:`.Lateral` construct instead of
-an :class:`.Alias` which provides for the LATERAL keyword as well as special
+Above, we can see that the :meth:`_expression.Select.lateral` method acts a lot like
+the :meth:`_expression.Select.alias` method, including that we can specify an optional
+name.  However the construct is the :class:`_expression.Lateral` construct instead of
+an :class:`_expression.Alias` which provides for the LATERAL keyword as well as special
 instructions to allow correlation from inside the FROM clause of the
 enclosing statement.
 
-The :meth:`.Select.lateral` method interacts normally with the
-:meth:`.Select.correlate` and :meth:`.Select.correlate_except` methods, except
+The :meth:`_expression.Select.lateral` method interacts normally with the
+:meth:`_expression.Select.correlate` and :meth:`_expression.Select.correlate_except` methods, except
 that the correlation rules also apply to any other tables present in the
 enclosing statement's FROM clause.   Correlation is "automatic" to these
 tables by default, is explicit if the table is specified to
-:meth:`.Select.correlate`, and is explicit to all tables except those
-specified to :meth:`.Select.correlate_except`.
+:meth:`_expression.Select.correlate`, and is explicit to all tables except those
+specified to :meth:`_expression.Select.correlate_except`.
 
 
 .. versionadded:: 1.1
@@ -1989,9 +1988,9 @@ specified to :meth:`.Select.correlate_except`.
 
 .. seealso::
 
-    :class:`.Lateral`
+    :class:`_expression.Lateral`
 
-    :meth:`.Select.lateral`
+    :meth:`_expression.Select.lateral`
 
 
 .. _core_tutorial_ordering:
@@ -2000,7 +1999,7 @@ Ordering, Grouping, Limiting, Offset...ing...
 ---------------------------------------------
 
 Ordering is done by passing column expressions to the
-:meth:`~.SelectBase.order_by` method:
+:meth:`_expression.SelectBase.order_by` method:
 
 .. sourcecode:: pycon+sql
 
@@ -2011,8 +2010,8 @@ Ordering is done by passing column expressions to the
     ()
     {stop}[(u'jack',), (u'wendy',)]
 
-Ascending or descending can be controlled using the :meth:`~.ColumnElement.asc`
-and :meth:`~.ColumnElement.desc` modifiers:
+Ascending or descending can be controlled using the :meth:`_expression.ColumnElement.asc`
+and :meth:`_expression.ColumnElement.desc` modifiers:
 
 .. sourcecode:: pycon+sql
 
@@ -2025,7 +2024,7 @@ and :meth:`~.ColumnElement.desc` modifiers:
 
 Grouping refers to the GROUP BY clause, and is usually used in conjunction
 with aggregate functions to establish groups of rows to be aggregated.
-This is provided via the :meth:`~.SelectBase.group_by` method:
+This is provided via the :meth:`_expression.SelectBase.group_by` method:
 
 .. sourcecode:: pycon+sql
 
@@ -2041,7 +2040,7 @@ This is provided via the :meth:`~.SelectBase.group_by` method:
     {stop}[(u'jack', 2), (u'wendy', 2)]
 
 HAVING can be used to filter results on an aggregate value, after GROUP BY has
-been applied.  It's available here via the :meth:`~.Select.having`
+been applied.  It's available here via the :meth:`_expression.Select.having`
 method:
 
 .. sourcecode:: pycon+sql
@@ -2061,7 +2060,7 @@ method:
 
 A common system of dealing with duplicates in composed SELECT statements
 is the DISTINCT modifier.  A simple DISTINCT clause can be added using the
-:meth:`.Select.distinct` method:
+:meth:`_expression.Select.distinct` method:
 
 .. sourcecode:: pycon+sql
 
@@ -2081,8 +2080,8 @@ are returned, and the majority also feature a means of starting to return
 rows after a given "offset".   While common backends like PostgreSQL,
 MySQL and SQLite support LIMIT and OFFSET keywords, other backends
 need to refer to more esoteric features such as "window functions"
-and row ids to achieve the same effect.  The :meth:`~.Select.limit`
-and :meth:`~.Select.offset` methods provide an easy abstraction
+and row ids to achieve the same effect.  The :meth:`_expression.Select.limit`
+and :meth:`_expression.Select.offset` methods provide an easy abstraction
 into the current backend's methodology:
 
 .. sourcecode:: pycon+sql
@@ -2103,9 +2102,9 @@ into the current backend's methodology:
 Inserts, Updates and Deletes
 ============================
 
-We've seen :meth:`~.TableClause.insert` demonstrated
-earlier in this tutorial.   Where :meth:`~.TableClause.insert`
-produces INSERT, the :meth:`~.TableClause.update`
+We've seen :meth:`_expression.TableClause.insert` demonstrated
+earlier in this tutorial.   Where :meth:`_expression.TableClause.insert`
+produces INSERT, the :meth:`_expression.TableClause.update`
 method produces UPDATE.  Both of these constructs feature
 a method called :meth:`~.ValuesBase.values` which specifies
 the VALUES or SET clause of the statement.
@@ -2123,16 +2122,16 @@ as a value:
     COMMIT
     {stop}<sqlalchemy.engine.result.ResultProxy object at 0x...>
 
-When using :meth:`~.TableClause.insert` or :meth:`~.TableClause.update`
+When using :meth:`_expression.TableClause.insert` or :meth:`_expression.TableClause.update`
 in an "execute many" context, we may also want to specify named
 bound parameters which we can refer to in the argument list.
 The two constructs will automatically generate bound placeholders
 for any column names passed in the dictionaries sent to
-:meth:`~.Connection.execute` at execution time.  However, if we
+:meth:`_engine.Connection.execute` at execution time.  However, if we
 wish to use explicitly targeted named parameters with composed expressions,
-we need to use the :func:`~.expression.bindparam` construct.
-When using :func:`~.expression.bindparam` with
-:meth:`~.TableClause.insert` or :meth:`~.TableClause.update`,
+we need to use the :func:`_expression.bindparam` construct.
+When using :func:`_expression.bindparam` with
+:meth:`_expression.TableClause.insert` or :meth:`_expression.TableClause.update`,
 the names of the table's columns themselves are reserved for the
 "automatic" generation of bind names.  We can combine the usage
 of implicitly available bind names and explicitly named parameters
@@ -2152,7 +2151,7 @@ as in the example below:
     COMMIT
     <sqlalchemy.engine.result.ResultProxy object at 0x...>
 
-An UPDATE statement is emitted using the :meth:`~.TableClause.update` construct.  This
+An UPDATE statement is emitted using the :meth:`_expression.TableClause.update` construct.  This
 works much like an INSERT, except there is an additional WHERE clause
 that can be specified:
 
@@ -2168,9 +2167,9 @@ that can be specified:
     COMMIT
     {stop}<sqlalchemy.engine.result.ResultProxy object at 0x...>
 
-When using :meth:`~.TableClause.update` in an "executemany" context,
+When using :meth:`_expression.TableClause.update` in an "executemany" context,
 we may wish to also use explicitly named bound parameters in the
-WHERE clause.  Again, :func:`~.expression.bindparam` is the construct
+WHERE clause.  Again, :func:`_expression.bindparam` is the construct
 used to achieve this:
 
 .. sourcecode:: pycon+sql
@@ -2194,7 +2193,7 @@ Correlated Updates
 
 A correlated update lets you update a table using selection from another
 table, or the same table; the SELECT statement is passed as a scalar
-subquery using :meth:`.Select.scalar_subquery`:
+subquery using :meth:`_expression.Select.scalar_subquery`:
 
 .. sourcecode:: pycon+sql
 
@@ -2220,7 +2219,7 @@ that refer to multiple tables.   For PG and MSSQL, this is the "UPDATE FROM" syn
 which updates one table at a time, but can reference additional tables in an additional
 "FROM" clause that can then be referenced in the WHERE clause directly.   On MySQL,
 multiple tables can be embedded into a single UPDATE statement separated by a comma.
-The SQLAlchemy :func:`.update` construct supports both of these modes
+The SQLAlchemy :func:`_expression.update` construct supports both of these modes
 implicitly, by specifying multiple tables in the WHERE clause::
 
     stmt = users.update().\
@@ -2236,7 +2235,7 @@ The resulting SQL from the above statement would render as::
     addresses.email_address LIKE :email_address_1 || '%'
 
 When using MySQL, columns from each table can be assigned to in the
-SET clause directly, using the dictionary form passed to :meth:`.Update.values`::
+SET clause directly, using the dictionary form passed to :meth:`_expression.Update.values`::
 
     stmt = users.update().\
             values({
@@ -2263,14 +2262,14 @@ construct.
 Parameter-Ordered Updates
 -------------------------
 
-The default behavior of the :func:`.update` construct when rendering the SET
+The default behavior of the :func:`_expression.update` construct when rendering the SET
 clauses is to render them using the column ordering given in the
-originating :class:`.Table` object.
+originating :class:`_schema.Table` object.
 This is an important behavior, since it means that the rendering of a
 particular UPDATE statement with particular columns
 will be rendered the same each time, which has an impact on query caching systems
 that rely on the form of the statement, either client side or server side.
-Since the parameters themselves are passed to the :meth:`.Update.values`
+Since the parameters themselves are passed to the :meth:`_expression.Update.values`
 method as Python dictionary keys, there is no other fixed ordering
 available.
 
@@ -2290,7 +2289,7 @@ a per-value basis, as opposed to on a per-row basis, and as each SET clause
 is evaluated, the values embedded in the row are changing.
 
 To suit this specific use case, the
-:meth:`.update.ordered_values` method may be used.  When using this method,
+:meth:`_expression.update.ordered_values` method may be used.  When using this method,
 we supply a **series of 2-tuples**
 as the argument to the method::
 
@@ -2302,8 +2301,8 @@ dictionary, except that it explicitly suggests a specific ordering. Using the
 above form, we are assured that the "y" column's SET clause will render first,
 then the "x" column's SET clause.
 
-.. versionchanged:: 1.4  Added the :meth:`.Update.ordered_values` method which
-   supersedes the :paramref:`.update.preserve_parameter_order` flag that will
+.. versionchanged:: 1.4  Added the :meth:`_expression.Update.ordered_values` method which
+   supersedes the :paramref:`_expression.update.preserve_parameter_order` flag that will
    be removed in SQLAlchemy 2.0.
 
 .. seealso::
@@ -2317,7 +2316,7 @@ Deletes
 -------
 
 Finally, a delete.  This is accomplished easily enough using the
-:meth:`~.TableClause.delete` construct:
+:meth:`_expression.TableClause.delete` construct:
 
 .. sourcecode:: pycon+sql
 
@@ -2344,7 +2343,7 @@ The PostgreSQL, Microsoft SQL Server, and MySQL backends all support DELETE
 statements that refer to multiple tables within the WHERE criteria.   For PG
 and MySQL, this is the "DELETE USING" syntax, and for SQL Server, it's a
 "DELETE FROM" that refers to more than one table.  The SQLAlchemy
-:func:`.delete` construct supports both of these modes
+:func:`_expression.delete` construct supports both of these modes
 implicitly, by specifying multiple tables in the WHERE clause::
 
     stmt = users.delete().\
@@ -2367,8 +2366,8 @@ construct.
 Matched Row Counts
 ------------------
 
-Both of :meth:`~.TableClause.update` and
-:meth:`~.TableClause.delete` are associated with *matched row counts*.  This is a
+Both of :meth:`_expression.TableClause.update` and
+:meth:`_expression.TableClause.delete` are associated with *matched row counts*.  This is a
 number indicating the number of rows that were matched by the WHERE clause.
 Note that by "matched", this includes rows where no UPDATE actually took place.
 The value is available as :attr:`~.ResultProxy.rowcount`:
diff --git a/doc/build/core/visitors.rst b/doc/build/core/visitors.rst
index 539d66440..6ef466265 100644
--- a/doc/build/core/visitors.rst
+++ b/doc/build/core/visitors.rst
@@ -6,7 +6,7 @@ that serve the purpose of generically **traversing** a Core SQL expression
 structure.   This is not unlike the Python ``ast`` module in that is presents
 a system by which a program can operate upon each component of a SQL
 expression.   Common purposes this serves are locating various kinds of
-elements such as :class:`.Table` or :class:`.BindParameter` objects,
+elements such as :class:`_schema.Table` or :class:`.BindParameter` objects,
 as well as altering the state of the structure such as replacing certain FROM
 clauses with others.