Remove needless gender specific terms. #855 (#2258)

Cleanup grating unmodern gender wording text in old PEPs that were pointed out
in #855.

pep-0311.txt

@@ -102,7 +102,7 @@ must continue to call ``Py_Initialize()``, and for multi-threaded
 applications, ``PyEval_InitThreads()``.  The reason for this is that
 the first thread to call ``PyEval_InitThreads()`` is nominated as the
 "main thread" by Python, and so forcing the extension author to
-specify the main thread (by forcing her to make this first call)
+specify the main thread (by requiring them to make this first call)
 removes ambiguity.  As ``Py_Initialize()`` must be called before
 ``PyEval_InitThreads()``, and as both of these functions currently
 support being called multiple times, the burden this places on

pep-0355.txt

@@ -82,7 +82,7 @@ current common practice:
 
 - Subclassability - the ``Path`` object can be extended to support
   paths other than filesystem paths.  The programmer does not need
-  to learn a new API, but can reuse his or her knowledge of Path
+  to learn a new API, but can reuse their knowledge of Path
   to deal with the extended class.
 
 - With all related functionality in one place, the right approach

pep-0381.txt

@@ -306,7 +306,7 @@ Extra package indexes
 
 It is obvious that some packages will not be uploaded to PyPI, whether
 because they are private or whether because the project maintainer
-runs his own server where people might get the project package.
+runs their own server where people might get the project package.
 However, it is strongly encouraged that a public package index follows
 PyPI and Distutils protocols.
 

pep-0458.txt

@@ -560,7 +560,7 @@ verification of PyPI distributions signed with private cryptographic
 keys stored on PyPI.  Distributions uploaded by developers are signed by PyPI
 and immediately available for download.  A possible future extension to this
 PEP, discussed in :pep:`480`, proposes the maximum security model and allows
-a developer to sign for his/her project.  Developer keys are not stored online:
+a developer to sign for their project.  Developer keys are not stored online:
 therefore, projects are safe from PyPI compromises.
 
 The minimum security model requires no action from a developer and protects

pep-3119.txt

@@ -115,7 +115,7 @@ documentation for the ABC.  These standard semantic definitions are
 not enforced, but are strongly recommended.
 
 Like all other things in Python, these promises are in the nature of a
-gentlemen's agreement, which in this case means that while the
+friendly agreement, which in this case means that while the
 language does enforce some of the promises made in the ABC, it is up
 to the implementer of the concrete class to insure that the remaining
 ones are kept.
@@ -153,7 +153,7 @@ MutableComposableSet, HashableComposableSet.
 
 The dilemma here is that we'd rather have fewer ABCs, but then what
 should a user do who needs a less refined ABC?  Consider e.g. the
-plight of a mathematician who wants to define his own kind of
+plight of a mathematician who wants to define their own kind of
 Transcendental numbers, but also wants float and int to be considered
 Transcendental.  :pep:`3141` originally proposed to patch float.__bases__
 for that purpose, but there are some good reasons to keep the built-in

pep-3127.txt

@@ -239,13 +239,13 @@ Assume the rare complete newcomer to computing who *does*, either
 occasionally or as a matter of habit, use leading zeros for decimal
 numbers.  Python could either:
 
-a) silently do the wrong thing with his numbers, as it does now;
+a) silently do the wrong thing with their numbers, as it does now;
 
-b) immediately disabuse him of the notion that this is viable syntax
+b) immediately disabuse them of the notion that this is viable syntax
    (and yes, the SyntaxWarning should be more gentle than it
    currently is, but that is a subject for a different PEP); or
 
-c) let him continue to think that computers are happy with
+c) let them continue to think that computers are happy with
    multi-digit decimal integers which start with "0".
 
 Some people passionately believe that (c) is the correct answer,
@@ -253,12 +253,11 @@ and they would be absolutely right if we could be sure that new
 users will never blossom and grow and start writing AJAX applications.
 
 So while a new Python user may (currently) be mystified at the
-delayed discovery that his numbers don't work properly, we can
+delayed discovery that their numbers don't work properly, we can
-fix it by explaining to him immediately that Python doesn't like
+fix it by explaining to them immediately that Python doesn't like
 leading zeros (hopefully with a reasonable message!), or we can
 delegate this teaching experience to the JavaScript interpreter
-in the Internet Explorer browser, and let him try to debug his
+in the browser, and let them try to debug their issue there.
-issue there.
 
 Supported radices
 -----------------