From: Mike Bayer Date: Sat, 30 Nov 2013 22:31:00 +0000 (-0500) Subject: - the pronoun removal commit. there was only one instance of a X-Git-Tag: rel_0_8_4~16 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f7e3a3a36cf9ebb2bbcc70c9b6c8d08710d6e14e;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git - the pronoun removal commit. there was only one instance of a standalone gendered pronoun with a gender-neutral subject, but also have replaced all occurences of "his/her", "his or her", etc. The docs have always strived to account for both genders in any non-specific singular pronoun, however recent controversy in the community suggests that a zero-gendered-pronoun policy is probably best going forward. --- diff --git a/doc/build/changelog/changelog_02.rst b/doc/build/changelog/changelog_02.rst index a2b0ab10bd..d85d57fdf6 100644 --- a/doc/build/changelog/changelog_02.rst +++ b/doc/build/changelog/changelog_02.rst @@ -203,7 +203,7 @@ turned on for individual table, schema, and column identifiers when used in all queries/creates/drops. Enabled via "quote=True" in Table or Column, as well as "quote_schema=True" in Table. Thanks to - Aaron Spike for his excellent efforts. + Aaron Spike for the excellent efforts. .. change:: :tags: diff --git a/doc/build/changelog/migration_08.rst b/doc/build/changelog/migration_08.rst index 971dd2f518..c8fbeb1d23 100644 --- a/doc/build/changelog/migration_08.rst +++ b/doc/build/changelog/migration_08.rst @@ -1235,7 +1235,7 @@ No more magic coercion of "=" to IN when comparing to subquery in MS-SQL ------------------------------------------------------------------------ We found a very old behavior in the MSSQL dialect which -would attempt to rescue the user from his or herself when +would attempt to rescue users from themselves when doing something like this: :: diff --git a/doc/build/orm/session.rst b/doc/build/orm/session.rst index fabd98808a..527235d369 100644 --- a/doc/build/orm/session.rst +++ b/doc/build/orm/session.rst @@ -252,7 +252,7 @@ one at a time. We refer to these two concepts as **transaction scope** and **session scope**. The implication here is that the SQLAlchemy ORM is encouraging the -developer to establish these two scopes in his or her application, +developer to establish these two scopes in their application, including not only when the scopes begin and end, but also the expanse of those scopes, for example should a single :class:`.Session` instance be local to the execution flow within a diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst index 466e3075b2..c824333e7d 100644 --- a/doc/build/orm/tutorial.rst +++ b/doc/build/orm/tutorial.rst @@ -424,7 +424,7 @@ We can add more ``User`` objects at once using ... User('mary', 'Mary Contrary', 'xxg527'), ... User('fred', 'Fred Flinstone', 'blah')]) -Also, Ed has already decided his password isn't too secure, so lets change it: +Also, we've decided the password for Ed isn't too secure, so lets change it: .. sourcecode:: python+sql @@ -1246,9 +1246,10 @@ using any SQL: >>> jack.addresses[1].user -Let's add and commit ``Jack Bean`` to the database. ``jack`` as well as the -two ``Address`` members in his ``addresses`` collection are both added to the -session at once, using a process known as **cascading**: +Let's add and commit ``Jack Bean`` to the database. ``jack`` as well +as the two ``Address`` members in the corresponding ``addresses`` +collection are both added to the session at once, using a process +known as **cascading**: .. sourcecode:: python+sql @@ -1842,8 +1843,8 @@ including the cascade configuration (we'll leave the constructor out too):: ... def __repr__(self): ... return "" % (self.name, self.fullname, self.password) -Then we recreate ``Address``, noting that in this case we've created the ``Address.user`` relationship -via the ``User`` class already:: +Then we recreate ``Address``, noting that in this case we've created +the ``Address.user`` relationship via the ``User`` class already:: >>> class Address(Base): ... __tablename__ = 'addresses' @@ -1854,9 +1855,10 @@ via the ``User`` class already:: ... def __repr__(self): ... return "" % self.email_address -Now when we load Jack (below using :meth:`~.Query.get`, which loads by primary key), -removing an address from his ``addresses`` collection will result in that -``Address`` being deleted: +Now when we load the user ``jack`` (below using :meth:`~.Query.get`, +which loads by primary key), removing an address from the +corresponding ``addresses`` collection will result in that ``Address`` +being deleted: .. sourcecode:: python+sql @@ -1897,7 +1899,8 @@ removing an address from his ``addresses`` collection will result in that ('jack@google.com', 'j25@yahoo.com') {stop}1 -Deleting Jack will delete both Jack and his remaining ``Address``: +Deleting Jack will delete both Jack and the remaining ``Address`` associated +with the user: .. sourcecode:: python+sql @@ -2116,8 +2119,8 @@ keyword string 'firstpost'": ('firstpost',) {stop}[BlogPost("Wendy's Blog Post", 'This is a test', )] -If we want to look up just Wendy's posts, we can tell the query to narrow down -to her as a parent: +If we want to look up posts owned by the user ``wendy``, we can tell +the query to narrow down to that ``User`` object as a parent: .. sourcecode:: python+sql diff --git a/examples/dogpile_caching/advanced.py b/examples/dogpile_caching/advanced.py index 6bfacfcf05..6b0638ea44 100644 --- a/examples/dogpile_caching/advanced.py +++ b/examples/dogpile_caching/advanced.py @@ -23,7 +23,7 @@ def load_name_range(start, end, invalidate=False): The `Person.addresses` collections are also cached. Its basically another level of tuning here, as that particular cache option can be transparently replaced with joinedload(Person.addresses). - The effect is that each Person and his/her Address collection + The effect is that each Person and their Address collection is cached either together or separately, affecting the kind of SQL that emits for unloaded Person objects as well as the distribution of data within the cache. diff --git a/examples/nested_sets/nested_sets.py b/examples/nested_sets/nested_sets.py index 8225a09f21..c64b15b61d 100644 --- a/examples/nested_sets/nested_sets.py +++ b/examples/nested_sets/nested_sets.py @@ -88,13 +88,13 @@ session.commit() print(session.query(Employee).all()) -# 1. Find an employee and all his/her supervisors, no matter how deep the tree. +# 1. Find an employee and all their supervisors, no matter how deep the tree. ealias = aliased(Employee) print(session.query(Employee).\ filter(ealias.left.between(Employee.left, Employee.right)).\ filter(ealias.emp == 'Eddie').all()) -#2. Find the employee and all his/her subordinates. +#2. Find the employee and all their subordinates. # (This query has a nice symmetry with the first query.) print(session.query(Employee).\ filter(Employee.left.between(ealias.left, ealias.right)).\ diff --git a/test/orm/test_assorted_eager.py b/test/orm/test_assorted_eager.py index a1c96bdfa4..e815f84b41 100644 --- a/test/orm/test_assorted_eager.py +++ b/test/orm/test_assorted_eager.py @@ -120,8 +120,8 @@ class EagerTest(fixtures.MappedTest): self.tables.categories) # I want to display a list of tests owned by owner 1 - # if someoption is false or he hasn't specified it yet (null) - # but not if he set it to true (example someoption is for hiding) + # if someoption is false or they haven't specified it yet (null) + # but not if they set it to true (example someoption is for hiding) # desired output for owner 1 # test_id, cat_name