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

12 files changed, 66 insertions, 51 deletions

diff --git a/lib/sqlalchemy/dialects/mssql/base.py b/lib/sqlalchemy/dialects/mssql/base.py
index b5c49246f..b0021e873 100644
--- a/lib/sqlalchemy/dialects/mssql/base.py
+++ b/lib/sqlalchemy/dialects/mssql/base.py
@@ -171,7 +171,8 @@ The process for fetching this value has several variants:
   * Other dialects such as pymssql will call upon
     ``SELECT scope_identity() AS lastrowid`` subsequent to an INSERT
     statement. If the flag ``use_scope_identity=False`` is passed to
-    :func:`.create_engine`, the statement ``SELECT @@identity AS lastrowid``
+    :func:`_sa.create_engine`,
+    the statement ``SELECT @@identity AS lastrowid``
     is used instead.
 
 A table that contains an ``IDENTITY`` column will prohibit an INSERT statement
@@ -293,8 +294,8 @@ Transaction Isolation Level
 
 All SQL Server dialects support setting of transaction isolation level
 both via a dialect-specific parameter
-:paramref:`.create_engine.isolation_level`
-accepted by :func:`.create_engine`,
+:paramref:`_sa.create_engine.isolation_level`
+accepted by :func:`_sa.create_engine`,
 as well as the :paramref:`.Connection.execution_options.isolation_level`
 argument as passed to
 :meth:`_engine.Connection.execution_options`.
@@ -302,7 +303,7 @@ This feature works by issuing the
 command ``SET TRANSACTION ISOLATION LEVEL <level>`` for
 each new connection.
 
-To set isolation level using :func:`.create_engine`::
+To set isolation level using :func:`_sa.create_engine`::
 
     engine = create_engine(
         "mssql+pyodbc://scott:tiger@ms_2008",
@@ -394,7 +395,7 @@ behavior of this flag is as follows:
   or ``False`` based on whether 2012 or greater is detected.
 
 * The flag can be set to either ``True`` or ``False`` when the dialect
-  is created, typically via :func:`.create_engine`::
+  is created, typically via :func:`_sa.create_engine`::
 
         eng = create_engine("mssql+pymssql://user:pass@host/db",
                         deprecate_large_types=True)
@@ -497,7 +498,7 @@ below::
 This mode of behavior is now off by default, as it appears to have served
 no purpose; however in the case that legacy applications rely upon it,
 it is available using the ``legacy_schema_aliasing`` argument to
-:func:`.create_engine` as illustrated above.
+:func:`_sa.create_engine` as illustrated above.
 
 .. versionchanged:: 1.1 the ``legacy_schema_aliasing`` flag introduced
    in version 1.0.5 to allow disabling of legacy mode for schemas now
@@ -638,7 +639,7 @@ Declarative form::
 
 
 This option can also be specified engine-wide using the
-``implicit_returning=False`` argument on :func:`.create_engine`.
+``implicit_returning=False`` argument on :func:`_sa.create_engine`.
 
 .. _mssql_rowcount_versioning:
 
diff --git a/lib/sqlalchemy/dialects/mssql/pyodbc.py b/lib/sqlalchemy/dialects/mssql/pyodbc.py
index ffaf66fdd..5cb92ef07 100644
--- a/lib/sqlalchemy/dialects/mssql/pyodbc.py
+++ b/lib/sqlalchemy/dialects/mssql/pyodbc.py
@@ -103,7 +103,8 @@ Microsoft ODBC drivers.  The feature is enabled by setting the flag
 ``.fast_executemany`` on the DBAPI cursor when an executemany call is to be
 used.   The SQLAlchemy pyodbc SQL Server dialect supports setting this flag
 automatically when the ``.fast_executemany`` flag is passed to
-:func:`.create_engine`; note that the ODBC driver must be the Microsoft driver
+:func:`_sa.create_engine`
+; note that the ODBC driver must be the Microsoft driver
 in order to use this flag::
 
     engine = create_engine(
diff --git a/lib/sqlalchemy/dialects/mysql/base.py b/lib/sqlalchemy/dialects/mysql/base.py
index e44dfa829..c7c3bd433 100644
--- a/lib/sqlalchemy/dialects/mysql/base.py
+++ b/lib/sqlalchemy/dialects/mysql/base.py
@@ -29,7 +29,7 @@ Connection Timeouts and Disconnects
 MySQL features an automatic connection close behavior, for connections that
 have been idle for a fixed period of time, defaulting to eight hours.
 To circumvent having this issue, use
-the :paramref:`.create_engine.pool_recycle` option which ensures that
+the :paramref:`_sa.create_engine.pool_recycle` option which ensures that
 a connection will be discarded and replaced with a new one if it has been
 present in the pool for a fixed number of seconds::
 
@@ -120,8 +120,9 @@ Transaction Isolation Level
 ---------------------------
 
 All MySQL dialects support setting of transaction isolation level both via a
-dialect-specific parameter :paramref:`.create_engine.isolation_level` accepted
-by :func:`.create_engine`, as well as the
+dialect-specific parameter :paramref:`_sa.create_engine.isolation_level`
+accepted
+by :func:`_sa.create_engine`, as well as the
 :paramref:`.Connection.execution_options.isolation_level` argument as passed to
 :meth:`_engine.Connection.execution_options`.
 This feature works by issuing the
@@ -129,7 +130,7 @@ command ``SET SESSION TRANSACTION ISOLATION LEVEL <level>`` for each new
 connection.  For the special AUTOCOMMIT isolation level, DBAPI-specific
 techniques are used.
 
-To set isolation level using :func:`.create_engine`::
+To set isolation level using :func:`_sa.create_engine`::
 
     engine = create_engine(
                     "mysql://scott:tiger@localhost/test",
@@ -198,7 +199,7 @@ will receive results.  The most typical way of invoking this feature is via the
 :paramref:`.Connection.execution_options.stream_results` connection execution
 option.   Server side cursors can also be enabled for all SELECT statements
 unconditionally by passing ``server_side_cursors=True`` to
-:func:`.create_engine`.
+:func:`_sa.create_engine`.
 
 .. versionadded:: 1.1.4 - added server-side cursor support.
 
@@ -468,7 +469,7 @@ This setting is currently hardcoded.
 
 .. seealso::
 
-    :attr:`.ResultProxy.rowcount`
+    :attr:`_engine.ResultProxy.rowcount`
 
 
 CAST Support
diff --git a/lib/sqlalchemy/dialects/oracle/base.py b/lib/sqlalchemy/dialects/oracle/base.py
index bbf65371c..50fa71d7e 100644
--- a/lib/sqlalchemy/dialects/oracle/base.py
+++ b/lib/sqlalchemy/dialects/oracle/base.py
@@ -125,7 +125,7 @@ As of SQLAlchemy 1.4, the default max identifier length for the Oracle dialect
 is 128 characters.  Upon first connect, the compatibility version is detected
 and if it is less than Oracle version 12.2, the max identifier length is
 changed to be 30 characters.  In all cases, setting the
-:paramref:`.create_engine.max_identifier_length` parameter will bypass this
+:paramref:`_sa.create_engine.max_identifier_length` parameter will bypass this
 change and the value given will be used as is::
 
     engine = create_engine(
@@ -183,7 +183,8 @@ database migration that wishes to "DROP CONSTRAINT" on a name that was
 previously generated with the shorter length.  This migration will fail when
 the identifier length is changed without the name of the index or constraint
 first being adjusted.  Such applications are strongly advised to make use of
-:paramref:`.create_engine.max_identifier_length` in order to maintain control
+:paramref:`_sa.create_engine.max_identifier_length`
+in order to maintain control
 of the generation of truncated names, and to fully review and test all database
 migrations in a staging environment when changing this value to ensure that the
 impact of this change has been mitigated.
@@ -206,7 +207,7 @@ There is currently a single option to affect its behavior:
 
 * the "FIRST_ROWS()" optimization keyword is not used by default.  To enable
   the usage of this optimization directive, specify ``optimize_limits=True``
-  to :func:`.create_engine`.
+  to :func:`_sa.create_engine`.
 
 .. versionchanged:: 1.4
     The Oracle dialect renders limit/offset integer values using a "post
@@ -242,7 +243,7 @@ on the Oracle backend.  By default, "implicit returning" typically only
 fetches the value of a single ``nextval(some_seq)`` expression embedded into
 an INSERT in order to increment a sequence within an INSERT statement and get
 the value back at the same time. To disable this feature across the board,
-specify ``implicit_returning=False`` to :func:`.create_engine`::
+specify ``implicit_returning=False`` to :func:`_sa.create_engine`::
 
     engine = create_engine("oracle://scott:tiger@dsn",
                            implicit_returning=False)
diff --git a/lib/sqlalchemy/dialects/oracle/cx_oracle.py b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
index 2cbf5b04a..b555c4555 100644
--- a/lib/sqlalchemy/dialects/oracle/cx_oracle.py
+++ b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
@@ -33,7 +33,7 @@ If ``dbname`` is not present, then the value of ``hostname`` in the
 URL is used directly as the DSN passed to ``cx_Oracle.connect()``.
 
 Additional connection arguments may be sent to the ``cx_Oracle.connect()``
-function using the :paramref:`.create_engine.connect_args` dictionary.
+function using the :paramref:`_sa.create_engine.connect_args` dictionary.
 Any cx_Oracle parameter value and/or constant may be passed, such as::
 
     import cx_Oracle
@@ -55,11 +55,12 @@ within the URL, which includes parameters such as ``mode``, ``purity``,
 .. versionchanged:: 1.3 the cx_oracle dialect now accepts all argument names
    within the URL string itself, to be passed to the cx_Oracle DBAPI.   As
    was the case earlier but not correctly documented, the
-   :paramref:`.create_engine.connect_args` parameter also accepts all
+   :paramref:`_sa.create_engine.connect_args` parameter also accepts all
    cx_Oracle DBAPI connect arguments.
 
 There are also options that are consumed by the SQLAlchemy cx_oracle dialect
-itself.  These options are always passed directly to :func:`.create_engine`,
+itself.  These options are always passed directly to :func:`_sa.create_engine`
+,
 such as::
 
     e = create_engine(
@@ -99,14 +100,15 @@ the VARCHAR2 and CLOB datatypes can accommodate the data.
 In the case that the Oracle database is not configured with a Unicode character
 set, the two options are to use the :class:`_oracle.NCHAR` and
 :class:`_oracle.NCLOB` datatypes explicitly, or to pass the flag
-``use_nchar_for_unicode=True`` to :func:`.create_engine`, which will cause the
+``use_nchar_for_unicode=True`` to :func:`_sa.create_engine`,
+which will cause the
 SQLAlchemy dialect to use NCHAR/NCLOB for the :class:`.Unicode` /
 :class:`.UnicodeText` datatypes instead of VARCHAR/CLOB.
 
 .. versionchanged:: 1.3  The :class:`.Unicode` and :class:`.UnicodeText`
    datatypes now correspond to the ``VARCHAR2`` and ``CLOB`` Oracle datatypes
    unless the ``use_nchar_for_unicode=True`` is passed to the dialect
-   when :func:`.create_engine` is called.
+   when :func:`_sa.create_engine` is called.
 
 When result sets are fetched that include strings, under Python 3 the cx_Oracle
 DBAPI returns all strings as Python Unicode objects, since Python 3 only has a
@@ -118,7 +120,7 @@ made use of converters that were supplied by cx_Oracle but were found to be
 non-performant; SQLAlchemy's own converters are used for the string to Unicode
 conversion under Python 2.  To disable the Python 2 Unicode conversion for
 VARCHAR2, CHAR, and CLOB, the flag ``coerce_to_unicode=False`` can be passed to
-:func:`.create_engine`.
+:func:`_sa.create_engine`.
 
 .. versionchanged:: 1.3 Unicode conversion is applied to all string values
    by default under python 2.  The ``coerce_to_unicode`` now defaults to True
@@ -235,7 +237,7 @@ As of the 6 series, this limitation has been lifted.  Nevertheless, because
 SQLAlchemy pre-reads these LOBs up front, this issue is avoided in any case.
 
 To disable the auto "read()" feature of the dialect, the flag
-``auto_convert_lobs=False`` may be passed to :func:`.create_engine`.  Under
+``auto_convert_lobs=False`` may be passed to :func:`_sa.create_engine`.  Under
 the cx_Oracle 5 series, having this flag turned off means there is the chance
 of reading from a stale LOB object if not read as it is fetched.   With
 cx_Oracle 6, this issue is resolved.
@@ -281,7 +283,7 @@ When no typing objects are present, as when executing plain SQL strings, a
 default "outputtypehandler" is present which will generally return numeric
 values which specify precision and scale as Python ``Decimal`` objects.  To
 disable this coercion to decimal for performance reasons, pass the flag
-``coerce_to_decimal=False`` to :func:`.create_engine`::
+``coerce_to_decimal=False`` to :func:`_sa.create_engine`::
 
     engine = create_engine("oracle+cx_oracle://dsn", coerce_to_decimal=False)
 
@@ -756,7 +758,7 @@ class OracleDialect_cx_oracle(OracleDialect):
             "in a future release.  As of version 1.3, it defaults to False "
             "rather than True.  The 'threaded' option can be passed to "
             "cx_Oracle directly in the URL query string passed to "
-            ":func:`.create_engine`.",
+            ":func:`_sa.create_engine`.",
         )
     )
     def __init__(
diff --git a/lib/sqlalchemy/dialects/postgresql/base.py b/lib/sqlalchemy/dialects/postgresql/base.py
index 670de4ebf..f9b3d9b95 100644
--- a/lib/sqlalchemy/dialects/postgresql/base.py
+++ b/lib/sqlalchemy/dialects/postgresql/base.py
@@ -41,7 +41,7 @@ apply; no RETURNING clause is emitted nor is the sequence pre-executed in this
 case.
 
 To force the usage of RETURNING by default off, specify the flag
-``implicit_returning=False`` to :func:`.create_engine`.
+``implicit_returning=False`` to :func:`_sa.create_engine`.
 
 PostgreSQL 10 IDENTITY columns
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -84,7 +84,8 @@ Transaction Isolation Level
 
 All PostgreSQL dialects support setting of transaction isolation level
 both via a dialect-specific parameter
-:paramref:`.create_engine.isolation_level` accepted by :func:`.create_engine`,
+:paramref:`_sa.create_engine.isolation_level` accepted by
+:func:`_sa.create_engine`,
 as well as the :paramref:`.Connection.execution_options.isolation_level`
 argument as passed to :meth:`_engine.Connection.execution_options`.
 When using a non-psycopg2 dialect, this feature works by issuing the command
@@ -92,7 +93,7 @@ When using a non-psycopg2 dialect, this feature works by issuing the command
 each new connection.  For the special AUTOCOMMIT isolation level,
 DBAPI-specific techniques are used.
 
-To set isolation level using :func:`.create_engine`::
+To set isolation level using :func:`_sa.create_engine`::
 
     engine = create_engine(
         "postgresql+pg8000://scott:tiger@localhost/test",
diff --git a/lib/sqlalchemy/dialects/postgresql/json.py b/lib/sqlalchemy/dialects/postgresql/json.py
index 811159953..953ad9993 100644
--- a/lib/sqlalchemy/dialects/postgresql/json.py
+++ b/lib/sqlalchemy/dialects/postgresql/json.py
@@ -154,7 +154,7 @@ class JSON(sqltypes.JSON):
     may be called upon the result type.
 
     Custom serializers and deserializers are specified at the dialect level,
-    that is using :func:`.create_engine`.  The reason for this is that when
+    that is using :func:`_sa.create_engine`.  The reason for this is that when
     using psycopg2, the DBAPI only allows serializers at the per-cursor
     or per-connection level.   E.g.::
 
@@ -274,7 +274,7 @@ class JSONB(JSON):
     are shared with the :class:`_types.JSON` class,
     using the ``json_serializer``
     and ``json_deserializer`` keyword arguments.  These must be specified
-    at the dialect level using :func:`.create_engine`.  When using
+    at the dialect level using :func:`_sa.create_engine`.  When using
     psycopg2, the serializers are associated with the jsonb type using
     ``psycopg2.extras.register_default_jsonb`` on a per-connection basis,
     in the same way that ``psycopg2.extras.register_default_json`` is used
diff --git a/lib/sqlalchemy/dialects/postgresql/pg8000.py b/lib/sqlalchemy/dialects/postgresql/pg8000.py
index b6e838738..197d11cf4 100644
--- a/lib/sqlalchemy/dialects/postgresql/pg8000.py
+++ b/lib/sqlalchemy/dialects/postgresql/pg8000.py
@@ -36,7 +36,7 @@ The ``client_encoding`` can be overridden for a session by executing the SQL:
 SET CLIENT_ENCODING TO 'utf8';
 
 SQLAlchemy will execute this SQL on all new connections based on the value
-passed to :func:`.create_engine` using the ``client_encoding`` parameter::
+passed to :func:`_sa.create_engine` using the ``client_encoding`` parameter::
 
     engine = create_engine(
         "postgresql+pg8000://user:pass@host/dbname", client_encoding='utf8')
diff --git a/lib/sqlalchemy/dialects/postgresql/psycopg2.py b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
index 6d2672bbe..769fbb06a 100644
--- a/lib/sqlalchemy/dialects/postgresql/psycopg2.py
+++ b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
@@ -15,7 +15,7 @@ psycopg2 Connect Arguments
 -----------------------------------
 
 psycopg2-specific keyword arguments which are accepted by
-:func:`.create_engine()` are:
+:func:`_sa.create_engine()` are:
 
 * ``server_side_cursors``: Enable the usage of "server side cursors" for SQL
   statements which support this feature. What this essentially means from a
@@ -161,7 +161,7 @@ when used with :ref:`multiple parameter
 sets <execute_multiple>`, which includes the use of this feature both by the
 Core as well as by the ORM for inserts of objects with non-autogenerated
 primary key values, by adding the ``executemany_mode`` flag to
-:func:`.create_engine`::
+:func:`_sa.create_engine`::
 
     engine = create_engine(
         "postgresql+psycopg2://scott:tiger@host/dbname",
@@ -251,7 +251,7 @@ A second way to affect the client encoding is to set it within Psycopg2
 locally.   SQLAlchemy will call psycopg2's
 :meth:`psycopg2:connection.set_client_encoding` method
 on all new connections based on the value passed to
-:func:`.create_engine` using the ``client_encoding`` parameter::
+:func:`_sa.create_engine` using the ``client_encoding`` parameter::
 
     # set_client_encoding() setting;
     # works for *all* PostgreSQL versions
@@ -263,11 +263,12 @@ When using the parameter in this way, the psycopg2 driver emits
 ``SET client_encoding TO 'utf8'`` on the connection explicitly, and works
 in all PostgreSQL versions.
 
-Note that the ``client_encoding`` setting as passed to :func:`.create_engine`
+Note that the ``client_encoding`` setting as passed to
+:func:`_sa.create_engine`
 is **not the same** as the more recently added ``client_encoding`` parameter
 now supported by libpq directly.   This is enabled when ``client_encoding``
 is passed directly to ``psycopg2.connect()``, and from SQLAlchemy is passed
-using the :paramref:`.create_engine.connect_args` parameter::
+using the :paramref:`_sa.create_engine.connect_args` parameter::
 
     engine = create_engine(
         "postgresql://user:pass@host/dbname",
@@ -288,10 +289,11 @@ SQLAlchemy can also be instructed to skip the usage of the psycopg2
 ``UNICODE`` extension and to instead utilize its own unicode encode/decode
 services, which are normally reserved only for those DBAPIs that don't
 fully support unicode directly.  Passing ``use_native_unicode=False`` to
-:func:`.create_engine` will disable usage of ``psycopg2.extensions.UNICODE``.
+:func:`_sa.create_engine` will disable usage of ``psycopg2.extensions.
+UNICODE``.
 SQLAlchemy will instead encode data itself into Python bytestrings on the way
 in and coerce from bytes on the way back,
-using the value of the :func:`.create_engine` ``encoding`` parameter, which
+using the value of the :func:`_sa.create_engine` ``encoding`` parameter, which
 defaults to ``utf-8``.
 SQLAlchemy's own unicode encode/decode functionality is steadily becoming
 obsolete as most DBAPIs now support unicode fully.
@@ -329,7 +331,7 @@ from the ``size_meters`` key as well.
 
 The other solution is to use a positional format; psycopg2 allows use of the
 "format" paramstyle, which can be passed to
-:paramref:`.create_engine.paramstyle`::
+:paramref:`_sa.create_engine.paramstyle`::
 
     engine = create_engine(
         'postgresql://scott:tiger@localhost:5432/test', paramstyle='format')
@@ -360,7 +362,8 @@ Psycopg2 Transaction Isolation Level
 
 As discussed in :ref:`postgresql_isolation_level`,
 all PostgreSQL dialects support setting of transaction isolation level
-both via the ``isolation_level`` parameter passed to :func:`.create_engine`,
+both via the ``isolation_level`` parameter passed to :func:`_sa.create_engine`
+,
 as well as the ``isolation_level`` argument used by
 :meth:`_engine.Connection.execution_options`.  When using the psycopg2 dialect
 , these
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.