]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
- the pronoun removal commit. there was only one instance of a
authorMike Bayer <mike_mp@zzzcomputing.com>
Sat, 30 Nov 2013 22:31:00 +0000 (17:31 -0500)
committerMike Bayer <mike_mp@zzzcomputing.com>
Sat, 30 Nov 2013 22:34:06 +0000 (17:34 -0500)
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.

doc/build/changelog/changelog_02.rst
doc/build/changelog/migration_08.rst
doc/build/orm/session.rst
doc/build/orm/tutorial.rst
examples/dogpile_caching/advanced.py
examples/nested_sets/nested_sets.py
test/orm/test_assorted_eager.py

index a2b0ab10bdd97cf586c0a4af1546575aef67d2c1..d85d57fdf62b79917efa83ac85701d7bb3246197 100644 (file)
       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: 
index 971dd2f5183fb817b9c3860ecb0755f5f1765a58..c8fbeb1d23ac7b07f220bfdf5bdd89105b336c9d 100644 (file)
@@ -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:
 
 ::
index fabd98808a1ff64823c239cfdee90bd9740b0281..527235d369233ff5a4efbdde06b9fef5bf717828 100644 (file)
@@ -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
index 466e3075b234ea68650d4584d4d69b03a9bfd61d..c824333e7d050e8da1a9a4732dec2a0146dbf243 100644 (file)
@@ -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
     <User('jack','Jack Bean', 'gjffdd')>
 
-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 "<User('%s','%s', '%s')>" % (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 "<Address('%s')>" % 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', <User('wendy','Wendy Williams', 'foobar')>)]
 
-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
 
index 6bfacfcf05c696cba37a46da09e29ce81aa02f7a..6b0638ea4424469ed8f942e65ff14aafc987a52f 100644 (file)
@@ -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.
index 8225a09f21cd96cc1f817006bf3b45c8b3b6569d..c64b15b61d4baff9974da2e8d4d2a20a6f724343 100644 (file)
@@ -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)).\
index a1c96bdfa40955b66f9e1517ccdb0c7308aabeab..e815f84b418819d6036352a92365a8b8c5945cbb 100644 (file)
@@ -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