Set up absolute references for create_engine and related

includes more replacements for create_engine(), Connection,
disambiguation of Result from future/baked

Change-Id: Icb60a79ee7a6c45ea9056c211ffd1be110da3b5e

3 files changed, 14 insertions, 9 deletions

diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py
index 1e265a9eb..dbc8c5e7f 100644
--- a/lib/sqlalchemy/dialects/sqlite/base.py
+++ b/lib/sqlalchemy/dialects/sqlite/base.py
@@ -179,7 +179,8 @@ default mode of ``SERIALIZABLE`` isolation, and a "dirty read" isolation
 mode normally referred to as ``READ UNCOMMITTED``.
 
 SQLAlchemy ties into this PRAGMA statement using the
-:paramref:`.create_engine.isolation_level` parameter of :func:`.create_engine`.
+:paramref:`_sa.create_engine.isolation_level` parameter of
+:func:`_sa.create_engine`.
 Valid values for this parameter when used with SQLite are ``"SERIALIZABLE"``
 and ``"READ UNCOMMITTED"`` corresponding to a value of 0 and 1, respectively.
 SQLite defaults to ``SERIALIZABLE``, however its behavior is impacted by
@@ -557,9 +558,9 @@ names are still addressable*::
     1
 
 Therefore, the workaround applied by SQLAlchemy only impacts
-:meth:`.ResultProxy.keys` and :meth:`.Row.keys()` in the public API. In
+:meth:`_engine.ResultProxy.keys` and :meth:`.Row.keys()` in the public API. In
 the very specific case where an application is forced to use column names that
-contain dots, and the functionality of :meth:`.ResultProxy.keys` and
+contain dots, and the functionality of :meth:`_engine.ResultProxy.keys` and
 :meth:`.Row.keys()` is required to return these dotted names unmodified,
 the ``sqlite_raw_colnames`` execution option may be provided, either on a
 per-:class:`_engine.Connection` basis::
diff --git a/lib/sqlalchemy/dialects/sqlite/pysqlcipher.py b/lib/sqlalchemy/dialects/sqlite/pysqlcipher.py
index a1243f271..213cc55f2 100644
--- a/lib/sqlalchemy/dialects/sqlite/pysqlcipher.py
+++ b/lib/sqlalchemy/dialects/sqlite/pysqlcipher.py
@@ -69,7 +69,8 @@ dialect here defaults to using the :class:`.SingletonThreadPool`
 implementation,
 instead of the :class:`.NullPool` pool used by pysqlite.  As always, the pool
 implementation is entirely configurable using the
-:paramref:`.create_engine.poolclass` parameter; the :class:`.StaticPool` may
+:paramref:`_sa.create_engine.poolclass` parameter; the :class:`.
+StaticPool` may
 be more feasible for single-threaded use, or :class:`.NullPool` may be used
 to prevent unencrypted connections from being held open for long periods of
 time, at the expense of slower startup time for new connections.
diff --git a/lib/sqlalchemy/dialects/sqlite/pysqlite.py b/lib/sqlalchemy/dialects/sqlite/pysqlite.py
index 307114c03..8da2a0323 100644
--- a/lib/sqlalchemy/dialects/sqlite/pysqlite.py
+++ b/lib/sqlalchemy/dialects/sqlite/pysqlite.py
@@ -72,7 +72,8 @@ as the "database" portion of the SQLAlchemy url (that is, following a slash)::
 
 .. note::  The "uri=true" parameter must appear in the **query string**
    of the URL.  It will not currently work as expected if it is only
-   present in the :paramref:`.create_engine.connect_args` parameter dictionary.
+   present in the :paramref:`_sa.create_engine.connect_args`
+   parameter dictionary.
 
 The logic reconciles the simultaneous presence of SQLAlchemy's query string and
 SQLite's query string by separating out the parameters that belong to the
@@ -99,15 +100,17 @@ Regarding future parameters added to either the Python or native drivers. new
 parameter names added to the SQLite URI scheme should be automatically
 accommodated by this scheme.  New parameter names added to the Python driver
 side can be accommodated by specifying them in the
-:paramref:`.create_engine.connect_args` dictionary, until dialect support is
+:paramref:`_sa.create_engine.connect_args` dictionary,
+until dialect support is
 added by SQLAlchemy.   For the less likely case that the native SQLite driver
 adds a new parameter name that overlaps with one of the existing, known Python
 driver parameters (such as "timeout" perhaps), SQLAlchemy's dialect would
 require adjustment for the URL scheme to continue to support this.
 
 As is always the case for all SQLAlchemy dialects, the entire "URL" process
-can be bypassed in :func:`.create_engine` through the use of the
-:paramref:`.create_engine.creator` parameter which allows for a custom callable
+can be bypassed in :func:`_sa.create_engine` through the use of the
+:paramref:`_sa.create_engine.creator`
+parameter which allows for a custom callable
 that creates a Python sqlite3 driver level connection directly.
 
 .. versionadded:: 1.3.9
@@ -326,7 +329,7 @@ ourselves. This is achieved using two event listeners::
 
 .. warning:: When using the above recipe, it is advised to not use the
    :paramref:`.Connection.execution_options.isolation_level` setting on
-   :class:`_engine.Connection` and :func:`.create_engine`
+   :class:`_engine.Connection` and :func:`_sa.create_engine`
    with the SQLite driver,
    as this function necessarily will also alter the ".isolation_level" setting.