diff --git a/pep-0311.txt b/pep-0311.txt index 1b7aabc53..0ff6cff28 100644 --- a/pep-0311.txt +++ b/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 diff --git a/pep-0355.txt b/pep-0355.txt index ed5cec73d..6d1a7c5bc 100644 --- a/pep-0355.txt +++ b/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 diff --git a/pep-0381.txt b/pep-0381.txt index f6e0fba7f..02f8ade34 100644 --- a/pep-0381.txt +++ b/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. diff --git a/pep-0458.txt b/pep-0458.txt index 00faedadf..437d3e74b 100644 --- a/pep-0458.txt +++ b/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 diff --git a/pep-3119.txt b/pep-3119.txt index 847456c30..11221b030 100644 --- a/pep-3119.txt +++ b/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 diff --git a/pep-3127.txt b/pep-3127.txt index ed495cc8b..05172ef3b 100644 --- a/pep-3127.txt +++ b/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 -fix it by explaining to him immediately that Python doesn't like +delayed discovery that their numbers don't work properly, we can +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 -issue there. +in the browser, and let them try to debug their issue there. Supported radices -----------------