From: Eric Hanchrow Date: Tue, 8 Aug 2023 21:43:14 +0000 (-0700) Subject: Replace `referred towards` with `referred to` throughout. X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=87e65f8a1eaf4d9a3fdac41506e620ae93c08c10;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git Replace `referred towards` with `referred to` throughout. `python3 -m tox` passes. --- diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst index fe2a02477c..edf3d75c38 100644 --- a/doc/build/changelog/changelog_11.rst +++ b/doc/build/changelog/changelog_11.rst @@ -209,7 +209,7 @@ Fixed bug where a descriptor that is elsewhere a mapped column or relationship within a hierarchy based on :class:`.AbstractConcreteBase` - would be referred towards during a refresh operation, causing an error + would be referred to during a refresh operation, causing an error as the attribute is not mapped as a mapper property. A similar issue can arise for other attributes like the "type" column added by :class:`.AbstractConcreteBase` if the class fails to include diff --git a/doc/build/changelog/changelog_13.rst b/doc/build/changelog/changelog_13.rst index 6039499692..2ecfec0de3 100644 --- a/doc/build/changelog/changelog_13.rst +++ b/doc/build/changelog/changelog_13.rst @@ -2746,7 +2746,7 @@ Fixed a series of quoting issues which all stemmed from the concept of the :func:`_expression.literal_column` construct, which when being "proxied" through a - subquery to be referred towards by a label that matches its text, the label + subquery to be referred to by a label that matches its text, the label would not have quoting rules applied to it, even if the string in the :class:`.Label` were set up as a :class:`.quoted_name` construct. Not applying quoting to the text of the :class:`.Label` is a bug because this diff --git a/doc/build/changelog/changelog_14.rst b/doc/build/changelog/changelog_14.rst index 8b68b04a81..90f0a66ccc 100644 --- a/doc/build/changelog/changelog_14.rst +++ b/doc/build/changelog/changelog_14.rst @@ -5056,7 +5056,7 @@ This document details individual issue-level changes made throughout Fixed a critical performance issue where the traversal of a :func:`_sql.select` construct would traverse a repetitive product of the - represented FROM clauses as they were each referred towards by columns in + represented FROM clauses as they were each referred to by columns in the columns clause; for a series of nested subqueries with lots of columns this could cause a large delay and significant memory growth. This traversal is used by a wide variety of SQL and ORM functions, including by @@ -6518,7 +6518,7 @@ This document details individual issue-level changes made throughout with an emphasis on its use within the :func:`_orm.with_loader_criteria` feature where it is most prominently used [ticket:5760]: - * fixed issue where boolean True/False values referred towards in the + * fixed issue where boolean True/False values referred to in the closure variables of the lambda would cause failures [ticket:5763] * Repaired a non-working detection for Python functions embedded in the @@ -6962,7 +6962,7 @@ This document details individual issue-level changes made throughout syntaxes supported by PostgreSQL, one of the most commonly requested features. Table valued functions are SQL functions that return lists of values or rows, and are prevalent in PostgreSQL in the area of JSON - functions, where the "table value" is commonly referred towards as the + functions, where the "table value" is commonly referred to as the "record" datatype. Table valued functions are also supported by Oracle and SQL Server. diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index 38139683c2..3350995400 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -2191,7 +2191,7 @@ Fixed regression related to the implementation for the new "insertmanyvalues" feature where an internal ``TypeError`` would occur in - arrangements where a :func:`_sql.insert` would be referred towards inside + arrangements where a :func:`_sql.insert` would be referred to inside of another :func:`_sql.insert` via a CTE; made additional repairs for this use case for positional dialects such as asyncpg when using "insertmanyvalues". diff --git a/doc/build/changelog/migration_13.rst b/doc/build/changelog/migration_13.rst index f7ce653f47..7703bc43e3 100644 --- a/doc/build/changelog/migration_13.rst +++ b/doc/build/changelog/migration_13.rst @@ -150,7 +150,7 @@ so that they did not conflict with the existing columns mapped to ``B``, as well as it was necessary to define a new primary key. With the new approach, all of this verbosity goes away, and the additional -columns are referred towards directly when making the relationship:: +columns are referred to directly when making the relationship:: j = join(B, D, D.b_id == B.id).join(C, C.id == D.c_id) diff --git a/doc/build/changelog/migration_20.rst b/doc/build/changelog/migration_20.rst index a830122554..0972705425 100644 --- a/doc/build/changelog/migration_20.rst +++ b/doc/build/changelog/migration_20.rst @@ -2007,7 +2007,7 @@ The new approach makes use of the :func:`_orm.aliased` construct so that the ORM internals don't need to guess which entities and columns should be adapted and in what way; in the example above, the ``ua`` and ``aa`` objects, both of which are :class:`_orm.AliasedClass` instances, provide to the internals -an unambiguous marker as to where the subquery should be referred towards +an unambiguous marker as to where the subquery should be referred to as well as what entity column or relationship is being considered for a given component of the query. diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst index 89d6df321d..1beb31e3e3 100644 --- a/doc/build/core/connections.rst +++ b/doc/build/core/connections.rst @@ -107,7 +107,7 @@ to the transaction ending, the :class:`_engine.Connection` waits for the :meth:`_engine.Connection.execute` method to be called again, at which point it autobegins again. -This calling style is referred towards as **commit as you go**, and is +This calling style is referred to as **commit as you go**, and is illustrated in the example below:: with engine.connect() as connection: @@ -159,7 +159,7 @@ Begin Once ~~~~~~~~~~ The :class:`_engine.Connection` object provides a more explicit transaction -management style referred towards as **begin once**. In contrast to "commit as +management style referred to as **begin once**. In contrast to "commit as you go", "begin once" allows the start point of the transaction to be stated explicitly, and allows that the transaction itself may be framed out as a context manager @@ -2199,7 +2199,7 @@ given exceeds a fixed limit, or when the total number of bound parameters to be rendered in a single INSERT statement exceeds a fixed limit (the two fixed limits are separate), multiple INSERT statements will be invoked within the scope of a single :meth:`_engine.Connection.execute` call, each of which -accommodate for a portion of the parameter dictionaries, referred towards as a +accommodate for a portion of the parameter dictionaries, referred to as a "batch". The number of parameter dictionaries represented within each "batch" is then known as the "batch size". For example, a batch size of 500 means that each INSERT statement emitted will INSERT at most 500 rows. diff --git a/doc/build/core/metadata.rst b/doc/build/core/metadata.rst index 4966970562..b926cb2e11 100644 --- a/doc/build/core/metadata.rst +++ b/doc/build/core/metadata.rst @@ -305,7 +305,7 @@ of referring to this alternate set of tables using a string name. SQLAlchemy refers to this name as the **schema name**. Within SQLAlchemy, this is nothing more than a string name which is associated with a :class:`_schema.Table` object, and is then rendered into SQL statements in a manner appropriate to the -target database such that the table is referred towards in its remote "schema", +target database such that the table is referred to in its remote "schema", whatever mechanism that is on the target database. The "schema" name may be associated directly with a :class:`_schema.Table` @@ -328,7 +328,7 @@ schema names on a per-connection or per-statement basis. "database" that typically has a single "owner". Within this database there can be any number of "schemas" which then contain the actual table objects. - A table within a specific schema is referred towards explicitly using the + A table within a specific schema is referred to explicitly using the syntax ".". Contrast this to an architecture such as that of MySQL, where there are only "databases", however SQL statements can refer to multiple databases at once, using the same syntax except it diff --git a/doc/build/core/reflection.rst b/doc/build/core/reflection.rst index 1ff517510e..7ea6f88b16 100644 --- a/doc/build/core/reflection.rst +++ b/doc/build/core/reflection.rst @@ -215,7 +215,7 @@ schemas will not require that the schema name be present (while at the same time it's also perfectly fine if the schema name *is* present). Since most relational databases therefore have the concept of a particular -table object which can be referred towards both in a schema-qualified way, as +table object which can be referred to both in a schema-qualified way, as well as an "implicit" way where no schema is present, this presents a complexity for SQLAlchemy's reflection feature. Reflecting a table in diff --git a/doc/build/errors.rst b/doc/build/errors.rst index bcfb43efb7..1a483e4193 100644 --- a/doc/build/errors.rst +++ b/doc/build/errors.rst @@ -678,7 +678,7 @@ construct:: The above pattern also allows an arbitrary selectable, such as a Core :class:`_sql.Join` or :class:`_sql.Alias` object, however there is no automatic adaptation of this element, meaning the -Core element would need to be referred towards directly:: +Core element would need to be referred to directly:: a1 = Address.__table__.alias() @@ -1196,7 +1196,7 @@ relationship X will copy column Q to column P, which conflicts with relationship This warning refers to the case when two or more relationships will write data to the same columns on flush, but the ORM does not have any means of coordinating these relationships together. Depending on specifics, the solution -may be that two relationships need to be referred towards one another using +may be that two relationships need to be referred to one another using :paramref:`_orm.relationship.back_populates`, or that one or more of the relationships should be configured with :paramref:`_orm.relationship.viewonly` to prevent conflicting writes, or sometimes that the configuration is fully diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst index 21c8a6ebfb..ee0d51fd18 100644 --- a/doc/build/glossary.rst +++ b/doc/build/glossary.rst @@ -304,7 +304,7 @@ Glossary aggregate the single row from each INSERT execution together. To overcome this limitation, SQLAlchemy as of the 2.0 series implements - an alternative form of "executemany" which is referred towards as + an alternative form of "executemany" which is referred to as :ref:`engine_insertmanyvalues`. This feature makes use of ``cursor.execute()`` to invoke an INSERT statement that will proceed with multiple parameter sets in one round trip, thus producing the same diff --git a/doc/build/orm/basic_relationships.rst b/doc/build/orm/basic_relationships.rst index 91353681ed..1cb483c314 100644 --- a/doc/build/orm/basic_relationships.rst +++ b/doc/build/orm/basic_relationships.rst @@ -1140,7 +1140,7 @@ using either a lambda callable or string name is supported, where string resolution works by evaluation of given Python expression which links identifier names to same-named :class:`_schema.Table` objects that are present in the same -:class:`_schema.MetaData` collection referred towards by the current +:class:`_schema.MetaData` collection referred to by the current :class:`_orm.registry`. For the example given at :ref:`relationships_many_to_many`, if we assumed diff --git a/doc/build/orm/composites.rst b/doc/build/orm/composites.rst index 4eaf7024a9..328aedd5f8 100644 --- a/doc/build/orm/composites.rst +++ b/doc/build/orm/composites.rst @@ -84,7 +84,7 @@ Working with Mapped Composite Column Types With a mapping as illustrated in the top section, we can work with the ``Vertex`` class, where the ``.start`` and ``.end`` attributes will -transparently refer to the columns referred towards by the ``Point`` class, as +transparently refer to the columns referred to by the ``Point`` class, as well as with instances of the ``Vertex`` class, where the ``.start`` and ``.end`` attributes will refer to instances of the ``Point`` class. The ``x1``, ``y1``, ``x2``, and ``y2`` columns are handled transparently: diff --git a/doc/build/orm/declarative_tables.rst b/doc/build/orm/declarative_tables.rst index 3d032b9a62..ae9080cb85 100644 --- a/doc/build/orm/declarative_tables.rst +++ b/doc/build/orm/declarative_tables.rst @@ -1218,7 +1218,7 @@ The above configuration is often more readable as an inline definition:: A natural effect of the above style is that the ``__table__`` attribute is itself defined within the class definition block. As such it may be -immediately referred towards within subsequent attributes, such as the example +immediately referred to within subsequent attributes, such as the example below which illustrates referring to the ``type`` column in a polymorphic mapper configuration:: @@ -1699,7 +1699,7 @@ Similarly:: will map the ``Address`` class to the ``address_table`` table, including all columns present except ``street``, ``city``, ``state``, and ``zip``. -As indicated in the two examples, columns may be referred towards either +As indicated in the two examples, columns may be referred to either by string name or by referring to the :class:`_schema.Column` object directly. Referring to the object directly may be useful for explicitness as well as to resolve ambiguities when diff --git a/doc/build/orm/inheritance.rst b/doc/build/orm/inheritance.rst index 6746a0cda5..a6f038593c 100644 --- a/doc/build/orm/inheritance.rst +++ b/doc/build/orm/inheritance.rst @@ -424,7 +424,7 @@ parameter indicates to :func:`_orm.mapped_column` that it should look for the requested :class:`_schema.Column` on the mapped :class:`.Table` for ``Employee`` first, and if present, maintain that existing mapping. If not present, :func:`_orm.mapped_column` will map the column normally, adding it -as one of the columns in the :class:`.Table` referred towards by the +as one of the columns in the :class:`.Table` referred to by the ``Employee`` superclass. diff --git a/doc/build/orm/mapping_styles.rst b/doc/build/orm/mapping_styles.rst index 72d540090f..fbe4267be7 100644 --- a/doc/build/orm/mapping_styles.rst +++ b/doc/build/orm/mapping_styles.rst @@ -89,7 +89,7 @@ the use of a declarative base which is then used in a declarative table mapping: nickname: Mapped[Optional[str]] Above, the :class:`_orm.DeclarativeBase` class is used to generate a new -base class (within SQLAlchemy's documentation it's typically referred towards +base class (within SQLAlchemy's documentation it's typically referred to as ``Base``, however can have any desired name) from which new classes to be mapped may inherit from, as above a new mapped class ``User`` is constructed. diff --git a/doc/build/orm/queryguide/inheritance.rst b/doc/build/orm/queryguide/inheritance.rst index 7040128f40..b058110fea 100644 --- a/doc/build/orm/queryguide/inheritance.rst +++ b/doc/build/orm/queryguide/inheritance.rst @@ -344,7 +344,7 @@ In contrast to :func:`_orm.selectin_polymorphic` which affects only the loading of objects, the :func:`_orm.with_polymorphic` construct affects how the SQL query for a polymorphic structure is rendered, most commonly as a series of LEFT OUTER JOINs to each of the included sub-tables. This join structure is -referred towards as the **polymorphic selectable**. By providing for a view of +referred to as the **polymorphic selectable**. By providing for a view of several sub-tables at once, :func:`_orm.with_polymorphic` offers a means of writing a SELECT statement across several inherited classes at once with the ability to add filtering criteria based on individual sub-tables. @@ -445,7 +445,7 @@ statement. To use this feature with a joined inheritance mapping, we typically want to pass two parameters, :paramref:`_orm.with_polymorphic.aliased` as well as :paramref:`_orm.with_polymorphic.flat`. The :paramref:`_orm.with_polymorphic.aliased` -parameter indicates that the polymorphic selectable should be referred towards +parameter indicates that the polymorphic selectable should be referred to by an alias name that is unique to this construct. The :paramref:`_orm.with_polymorphic.flat` parameter is specific to the default LEFT OUTER JOIN polymorphic selectable and indicates that a more optimized diff --git a/doc/build/orm/queryguide/select.rst b/doc/build/orm/queryguide/select.rst index c14eb134e4..eff2c6b9f9 100644 --- a/doc/build/orm/queryguide/select.rst +++ b/doc/build/orm/queryguide/select.rst @@ -798,7 +798,7 @@ applied to more than one :func:`_orm.aliased` construct at once, and used in the same :class:`.Select` construct in terms of each entity separately. The rendered SQL will continue to treat all such :func:`_orm.aliased` constructs as the same subquery, however from the ORM / Python perspective -the different return values and object attributes can be referred towards +the different return values and object attributes can be referred to by using the appropriate :func:`_orm.aliased` construct. Given for example a subquery that refers to both ``User`` and ``Address``:: @@ -1049,7 +1049,7 @@ in terms of the target :func:`_orm.relationship`. * **An object has a particular parent from a one-to-many perspective** - the :func:`_orm.with_parent` function produces a comparison that returns rows - which are referred towards by a given parent, this is essentially the + which are referred to by a given parent, this is essentially the same as using the ``==`` operator with the many-to-one side:: >>> from sqlalchemy.orm import with_parent diff --git a/doc/build/orm/quickstart.rst b/doc/build/orm/quickstart.rst index 9c693e027d..55a22e419a 100644 --- a/doc/build/orm/quickstart.rst +++ b/doc/build/orm/quickstart.rst @@ -103,10 +103,10 @@ of the key. In the above example, the ``User.id`` and ``Address.id`` columns are marked as primary key. Taken together, the combination of a string table name as well as a list -of column declarations is referred towards in SQLAlchemy as :term:`table metadata`. +of column declarations is referred to in SQLAlchemy as :term:`table metadata`. Setting up table metadata using both Core and ORM approaches is introduced in the :ref:`unified_tutorial` at :ref:`tutorial_working_with_metadata`. -The above mapping is an example of what's referred towards as +The above mapping is an example of what's referred to as :ref:`Annotated Declarative Table ` configuration. diff --git a/doc/build/tutorial/data_select.rst b/doc/build/tutorial/data_select.rst index 03bc459a1f..1ae8b02351 100644 --- a/doc/build/tutorial/data_select.rst +++ b/doc/build/tutorial/data_select.rst @@ -255,7 +255,7 @@ when referring to arbitrary SQL expressions in a result row by name: .. seealso:: :ref:`tutorial_order_by_label` - the label names we create may also be - referred towards in the ORDER BY or GROUP BY clause of the :class:`_sql.Select`. + referred to in the ORDER BY or GROUP BY clause of the :class:`_sql.Select`. .. _tutorial_select_arbitrary_text: @@ -682,7 +682,7 @@ Now that we are selecting from multiple tables and using joins, we quickly run into the case where we need to refer to the same table multiple times in the FROM clause of a statement. We accomplish this using SQL **aliases**, which are a syntax that supplies an alternative name to a table or subquery -from which it can be referred towards in the statement. +from which it can be referred to in the statement. In the SQLAlchemy Expression Language, these "names" are instead represented by :class:`_sql.FromClause` objects known as the :class:`_sql.Alias` construct, @@ -1163,7 +1163,7 @@ that it has fewer methods. The :class:`_sql.CompoundSelect` produced by To use a :class:`_sql.CompoundSelect` as a subquery, just like :class:`_sql.Select` it provides a :meth:`_sql.SelectBase.subquery` method which will produce a :class:`_sql.Subquery` object with a :attr:`_sql.FromClause.c` -collection that may be referred towards in an enclosing :func:`_sql.select`:: +collection that may be referred to in an enclosing :func:`_sql.select`:: >>> u_subq = u.subquery() >>> stmt = ( @@ -1422,7 +1422,7 @@ something like :class:`_types.Integer` or :class:`_types.Numeric`, JSON accessors in order to work need to be using a type such as :class:`_types.JSON`. Certain classes of functions return entire rows instead of column values, where there is a need to refer to specific columns; -such functions are referred towards +such functions are referred to as :ref:`table valued functions `. The SQL return type of the function may also be significant when executing a @@ -1676,7 +1676,7 @@ Table-Valued Functions Table-valued SQL functions support a scalar representation that contains named sub-elements. Often used for JSON and ARRAY-oriented functions as well as functions like ``generate_series()``, the table-valued function is specified in -the FROM clause, and is then referred towards as a table, or sometimes even as +the FROM clause, and is then referred to as a table, or sometimes even as a column. Functions of this form are prominent within the PostgreSQL database, however some forms of table valued functions are also supported by SQLite, Oracle, and SQL Server. diff --git a/doc/build/tutorial/dbapi_transactions.rst b/doc/build/tutorial/dbapi_transactions.rst index aecc3e6bae..4a481be818 100644 --- a/doc/build/tutorial/dbapi_transactions.rst +++ b/doc/build/tutorial/dbapi_transactions.rst @@ -137,7 +137,7 @@ connection, rather than the :meth:`_engine.Engine.connect` method. This method will both manage the scope of the :class:`_engine.Connection` and also enclose everything inside of a transaction with COMMIT at the end, assuming a successful block, or ROLLBACK in case of exception raise. This style -may be referred towards as **begin once**: +may be referred to as **begin once**: .. sourcecode:: pycon+sql @@ -301,7 +301,7 @@ Sending Parameters SQL statements are usually accompanied by data that is to be passed with the statement itself, as we saw in the INSERT example previously. The :meth:`_engine.Connection.execute` method therefore also accepts parameters, -which are referred towards as :term:`bound parameters`. A rudimentary example +which are referred to as :term:`bound parameters`. A rudimentary example might be if we wanted to limit our SELECT statement only to rows that meet a certain criteria, such as rows where the "y" value were greater than a certain value that is passed in to a function. diff --git a/doc/build/tutorial/metadata.rst b/doc/build/tutorial/metadata.rst index 8ee87480af..bddc9b17df 100644 --- a/doc/build/tutorial/metadata.rst +++ b/doc/build/tutorial/metadata.rst @@ -415,7 +415,7 @@ types:: ... def __repr__(self) -> str: ... return f"Address(id={self.id!r}, email_address={self.email_address!r})" -The two classes above, ``User`` and ``Address``, are now referred towards +The two classes above, ``User`` and ``Address``, are now referred to as **ORM Mapped Classes**, and are available for use in ORM persistence and query operations, which will be described later. Details about these classes include: @@ -427,7 +427,7 @@ about these classes include: from the :attr:`_orm.DeclarativeBase.__table__` attribute. * As mentioned previously, this form - is referred towards as :ref:`orm_declarative_table_configuration`. One + is referred to as :ref:`orm_declarative_table_configuration`. One of several alternative declaration styles would instead have us build the :class:`_schema.Table` object directly, and **assign** it directly to :attr:`_orm.DeclarativeBase.__table__`. This style diff --git a/doc/build/tutorial/orm_related_objects.rst b/doc/build/tutorial/orm_related_objects.rst index e10288a21c..470ad4ac47 100644 --- a/doc/build/tutorial/orm_related_objects.rst +++ b/doc/build/tutorial/orm_related_objects.rst @@ -56,7 +56,7 @@ are mapped to the ``User`` and ``Address`` classes. As the table, the :func:`_orm.relationship` can determine unambiguously that there is a :term:`one to many` relationship from the ``User`` class to the ``Address`` class, along the ``User.addresses`` relationship; one particular row in the -``user_account`` table may be referred towards by many rows in the ``address`` +``user_account`` table may be referred to by many rows in the ``address`` table. All one-to-many relationships naturally correspond to a :term:`many to one` diff --git a/lib/sqlalchemy/dialects/postgresql/base.py b/lib/sqlalchemy/dialects/postgresql/base.py index 11f7d171da..233dce253a 100644 --- a/lib/sqlalchemy/dialects/postgresql/base.py +++ b/lib/sqlalchemy/dialects/postgresql/base.py @@ -303,7 +303,7 @@ Setting Alternate Search Paths on Connect ------------------------------------------ The PostgreSQL ``search_path`` variable refers to the list of schema names -that will be implicitly referred towards when a particular table or other +that will be implicitly referred to when a particular table or other object is referenced in a SQL statement. As detailed in the next section :ref:`postgresql_schema_reflection`, SQLAlchemy is generally organized around the concept of keeping this variable at its default value of ``public``, diff --git a/lib/sqlalchemy/dialects/postgresql/psycopg2.py b/lib/sqlalchemy/dialects/postgresql/psycopg2.py index 27f63ea6e1..10df44544e 100644 --- a/lib/sqlalchemy/dialects/postgresql/psycopg2.py +++ b/lib/sqlalchemy/dialects/postgresql/psycopg2.py @@ -254,7 +254,7 @@ equivalent to psycopg2's ``execute_values()`` handler; an overview of this feature and its configuration are at :ref:`engine_insertmanyvalues`. .. versionadded:: 2.0 Replaced psycopg2's ``execute_values()`` fast execution - helper with a native SQLAlchemy mechanism referred towards as + helper with a native SQLAlchemy mechanism referred to as :ref:`insertmanyvalues `. The psycopg2 dialect retains the ability to use the psycopg2-specific diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py index 835ec27731..3e17bb5832 100644 --- a/lib/sqlalchemy/dialects/sqlite/base.py +++ b/lib/sqlalchemy/dialects/sqlite/base.py @@ -843,7 +843,7 @@ Reflecting internal schema tables ---------------------------------- Reflection methods that return lists of tables will omit so-called -"SQLite internal schema object" names, which are referred towards by SQLite +"SQLite internal schema object" names, which are referred to by SQLite as any object name that is prefixed with ``sqlite_``. An example of such an object is the ``sqlite_sequence`` table that's generated when the ``AUTOINCREMENT`` column parameter is used. In order to return diff --git a/lib/sqlalchemy/engine/base.py b/lib/sqlalchemy/engine/base.py index b0cd721f1c..90a2e3fff6 100644 --- a/lib/sqlalchemy/engine/base.py +++ b/lib/sqlalchemy/engine/base.py @@ -814,7 +814,7 @@ class Connection(ConnectionEventsTarget, inspection.Inspectable["Inspector"]): The above code is not fundamentally any different in its behavior than the following code which does not use - :meth:`_engine.Connection.begin`; the below style is referred towards + :meth:`_engine.Connection.begin`; the below style is referred to as "commit as you go" style:: with engine.connect() as conn: diff --git a/lib/sqlalchemy/ext/hybrid.py b/lib/sqlalchemy/ext/hybrid.py index 83dfb50337..9daaf67d65 100644 --- a/lib/sqlalchemy/ext/hybrid.py +++ b/lib/sqlalchemy/ext/hybrid.py @@ -200,7 +200,7 @@ Using ``inplace`` to create pep-484 compliant hybrid properties In the previous section, a :class:`.hybrid_property` decorator is illustrated which includes two separate method-level functions being decorated, both -to produce a single object attribute referred towards as ``Interval.radius``. +to produce a single object attribute referred to as ``Interval.radius``. There are actually several different modifiers we can use for :class:`.hybrid_property` including :meth:`.hybrid_property.expression`, :meth:`.hybrid_property.setter` and :meth:`.hybrid_property.update_expression`. diff --git a/lib/sqlalchemy/orm/relationships.py b/lib/sqlalchemy/orm/relationships.py index e2ba698926..4c9655a1b3 100644 --- a/lib/sqlalchemy/orm/relationships.py +++ b/lib/sqlalchemy/orm/relationships.py @@ -1613,7 +1613,7 @@ class RelationshipProperty( @util.memoized_property def entity(self) -> _InternalEntityType[_T]: """Return the target mapped entity, which is an inspect() of the - class or aliased class that is referred towards. + class or aliased class that is referred to. """ self.parent._check_configure() @@ -1989,7 +1989,7 @@ class RelationshipProperty( 'and not on the "many" side of a many-to-one or many-to-many ' "relationship. " "To force this relationship to allow a particular " - '"%(relatedcls)s" object to be referred towards by only ' + '"%(relatedcls)s" object to be referred to by only ' 'a single "%(clsname)s" object at a time via the ' "%(rel)s relationship, which " "would allow " diff --git a/lib/sqlalchemy/orm/util.py b/lib/sqlalchemy/orm/util.py index 4371e6116f..8001852894 100644 --- a/lib/sqlalchemy/orm/util.py +++ b/lib/sqlalchemy/orm/util.py @@ -935,7 +935,7 @@ class AliasedInsp( """the AliasedClass that refers to this AliasedInsp""" _target: Union[Type[_O], AliasedClass[_O]] - """the thing referred towards by the AliasedClass/AliasedInsp. + """the thing referred to by the AliasedClass/AliasedInsp. In the vast majority of cases, this is the mapped class. However it may also be another AliasedClass (alias of alias). diff --git a/lib/sqlalchemy/sql/selectable.py b/lib/sqlalchemy/sql/selectable.py index 060b03b503..2bb5d272a3 100644 --- a/lib/sqlalchemy/sql/selectable.py +++ b/lib/sqlalchemy/sql/selectable.py @@ -2436,7 +2436,7 @@ class HasCTE(roles.HasCTERole, SelectsRows): SELECT t.c1, t.c2 FROM t - Above, the "anon_1" CTE is not referred towards in the SELECT + Above, the "anon_1" CTE is not referred to in the SELECT statement, however still accomplishes the task of running an INSERT statement. diff --git a/lib/sqlalchemy/sql/visitors.py b/lib/sqlalchemy/sql/visitors.py index 69dc6a827c..6b94ca271d 100644 --- a/lib/sqlalchemy/sql/visitors.py +++ b/lib/sqlalchemy/sql/visitors.py @@ -170,7 +170,7 @@ class InternalTraversal(Enum): Above, the :class:`.Case` class indicates its internal state as the attributes named ``value``, ``whens``, and ``else_``. They each link to an :class:`.InternalTraversal` method which indicates the type - of datastructure referred towards. + of datastructure referred to. Using the ``_traverse_internals`` structure, objects of type :class:`.InternalTraversible` will have the following methods automatically