From 04a6af2ab1b19a56db74d5ae85a96656cc04bfa6 Mon Sep 17 00:00:00 2001 From: Marti Raudsepp Date: Mon, 11 Jul 2016 18:14:08 +0300 Subject: [PATCH] Fix various typos, spelling and grammar errors Errors detected using Topy (https://github.com/intgr/topy), all changes verified by hand. --- pep-0004.txt | 2 +- pep-0007.txt | 2 +- pep-0008.txt | 2 +- pep-0100.txt | 2 +- pep-0101.txt | 2 +- pep-0103.txt | 2 +- pep-0201.txt | 2 +- pep-0204.txt | 2 +- pep-0205.txt | 4 ++-- pep-0209.txt | 8 ++++---- pep-0213.txt | 2 +- pep-0216.txt | 4 ++-- pep-0217.txt | 2 +- pep-0219.txt | 2 +- pep-0221.txt | 6 +++--- pep-0225.txt | 6 +++--- pep-0231.txt | 2 +- pep-0240.txt | 2 +- pep-0245.txt | 10 +++++----- pep-0247.txt | 2 +- pep-0249.txt | 2 +- pep-0255.txt | 4 ++-- pep-0258.txt | 2 +- pep-0259.txt | 2 +- pep-0261.txt | 2 +- pep-0268.txt | 2 +- pep-0273.txt | 4 ++-- pep-0275.txt | 4 ++-- pep-0276.txt | 6 +++--- pep-0278.txt | 2 +- pep-0285.txt | 2 +- pep-0289.txt | 2 +- pep-0290.txt | 2 +- pep-0293.txt | 6 +++--- pep-0295.txt | 2 +- pep-0296.txt | 2 +- pep-0298.txt | 2 +- pep-0302.txt | 4 ++-- pep-0305.txt | 4 ++-- pep-0307.txt | 2 +- pep-0308.txt | 4 ++-- pep-0312.txt | 2 +- pep-0313.txt | 2 +- pep-0318.txt | 2 +- pep-0319.txt | 6 +++--- pep-0323.txt | 2 +- pep-0325.txt | 4 ++-- pep-0327.txt | 4 ++-- pep-0333.txt | 4 ++-- pep-0334.txt | 2 +- pep-0339.txt | 2 +- pep-0343.txt | 2 +- pep-0344.txt | 4 ++-- pep-0345.txt | 4 ++-- pep-0346.txt | 2 +- pep-0348.txt | 2 +- pep-0357.txt | 6 +++--- pep-0358.txt | 4 ++-- pep-0368.txt | 2 +- pep-0369.txt | 6 +++--- pep-0370.txt | 4 ++-- pep-0374.txt | 2 +- pep-0379.txt | 2 +- pep-0380.txt | 2 +- pep-0381.txt | 10 +++++----- pep-0382.txt | 2 +- pep-0386.txt | 2 +- pep-0387.txt | 4 ++-- pep-0390.txt | 6 +++--- pep-0396.txt | 2 +- pep-0397.txt | 2 +- pep-0399.txt | 2 +- pep-0401.txt | 2 +- pep-0406.txt | 2 +- pep-0409.txt | 2 +- pep-0412.txt | 2 +- pep-0413.txt | 2 +- pep-0418.txt | 4 ++-- pep-0418/clockutils.py | 2 +- pep-0419.txt | 2 +- pep-0423.txt | 6 +++--- pep-0425.txt | 2 +- pep-0426.txt | 4 ++-- pep-0428.txt | 2 +- pep-0431.txt | 6 +++--- pep-0432.txt | 8 ++++---- pep-0433.txt | 6 +++--- pep-0436.txt | 2 +- pep-0440.txt | 18 +++++++++--------- pep-0444.txt | 2 +- pep-0445.txt | 6 +++--- pep-0446.txt | 2 +- pep-0447.txt | 8 ++++---- pep-0449.txt | 4 ++-- pep-0450.txt | 2 +- pep-0451.txt | 6 +++--- pep-0452.txt | 4 ++-- pep-0455.txt | 2 +- pep-0456.txt | 14 +++++++------- pep-0458.txt | 2 +- pep-0460.txt | 2 +- pep-0463.txt | 2 +- pep-0465.txt | 4 ++-- pep-0468.txt | 2 +- pep-0470.txt | 8 ++++---- pep-0471.txt | 2 +- pep-0474.txt | 4 ++-- pep-0475.txt | 2 +- pep-0477.txt | 4 ++-- pep-0481.txt | 10 +++++----- pep-0483.txt | 2 +- pep-0484.txt | 4 ++-- pep-0485.txt | 4 ++-- pep-0487.txt | 4 ++-- pep-0494.txt | 2 +- pep-0498.txt | 2 +- pep-0499.txt | 2 +- pep-0500.txt | 2 +- pep-0501.txt | 6 +++--- pep-0502.txt | 6 +++--- pep-0503.txt | 2 +- pep-0504.txt | 2 +- pep-0505.txt | 6 +++--- pep-0506.txt | 2 +- pep-0507.txt | 2 +- pep-0508.txt | 6 +++--- pep-0510.txt | 2 +- pep-0511.txt | 4 ++-- pep-0512.txt | 2 +- pep-0513.txt | 6 +++--- pep-0516.txt | 16 ++++++++-------- pep-0518.txt | 2 +- pep-0520.txt | 6 +++--- pep-0523.txt | 4 ++-- pep-0754.txt | 6 +++--- pep-3100.txt | 4 ++-- pep-3108.txt | 8 ++++---- pep-3118.txt | 10 +++++----- pep-3127.txt | 6 +++--- pep-3131.txt | 2 +- pep-3134.txt | 4 ++-- pep-3145.txt | 2 +- pep-3153.txt | 2 +- pep-3156.txt | 4 ++-- pep-3333.txt | 8 ++++---- pep0/pep.py | 2 +- 146 files changed, 274 insertions(+), 274 deletions(-) diff --git a/pep-0004.txt b/pep-0004.txt index 21038ea4baf..0818cc65586 100644 --- a/pep-0004.txt +++ b/pep-0004.txt @@ -197,7 +197,7 @@ Deprecated modules Removed from the library reference in Python 2.5. Module name: mpz - Rationale: Third-party packages provide similiar features + Rationale: Third-party packages provide similar features and wrap more of GMP's API. Date: 10-Aug-2004 Documentation: This module has been documented as obsolete since diff --git a/pep-0007.txt b/pep-0007.txt index cd5c103554a..aa1ea0bb0a4 100644 --- a/pep-0007.txt +++ b/pep-0007.txt @@ -165,7 +165,7 @@ Documentation Strings #define PyDoc_STRVAR(name, str) PyDoc_VAR(name) = PyDoc_STR(str) #endif -* The first line of each fuction docstring should be a "signature +* The first line of each function docstring should be a "signature line" that gives a brief synopsis of the arguments and return value. For example:: diff --git a/pep-0008.txt b/pep-0008.txt index 26b3eea9829..c8c2857577f 100644 --- a/pep-0008.txt +++ b/pep-0008.txt @@ -1298,7 +1298,7 @@ annotations are changing. are now encouraged. For example, marking up a large third party library or application with PEP 484 style type annotations, reviewing how easy it was to add those annotations, and observing - whether their presence increases code understandabilty. + whether their presence increases code understandability. - The Python standard library should be conservative in adopting such annotations, but their use is allowed for new code and for big diff --git a/pep-0100.txt b/pep-0100.txt index 86ce1a74853..dfc041c880b 100644 --- a/pep-0100.txt +++ b/pep-0100.txt @@ -106,7 +106,7 @@ Unicode Default Encoding the encoding defined by the current locale. The locale module is used to extract the encoding from the locale default settings defined by the OS environment (see locale.py). If the encoding - cannot be determined, is unkown or unsupported, the code defaults + cannot be determined, is unknown or unsupported, the code defaults to setting the to 'ascii'. To enable this code, edit the site.py file or place the appropriate code into the sitecustomize.py module of your Python installation. diff --git a/pep-0101.txt b/pep-0101.txt index 747d47d1452..ac68235def3 100644 --- a/pep-0101.txt +++ b/pep-0101.txt @@ -474,7 +474,7 @@ How to Make A Release permissions. (Or ask Ewa, who coordinated the effort for the new newbsite with RevSys.) - XXX This is completely out of date for Django based python.org. + XXX This is completely out of date for Django-based python.org. This page will probably come in handy: diff --git a/pep-0103.txt b/pep-0103.txt index 03aa66ae776..1386e9ff6f3 100644 --- a/pep-0103.txt +++ b/pep-0103.txt @@ -440,7 +440,7 @@ Read `how to recover from upstream rebase `_. It is in ``git help rebase``. -On the other hand don't be too afraid about commit editing. You can +On the other hand, don't be too afraid about commit editing. You can safely edit, reorder, remove, combine and split commits that haven't been pushed yet. You can even push commits to your own (backup) repo, edit them later and force-push edited commits to replace what have diff --git a/pep-0201.txt b/pep-0201.txt index 87155146bab..41bbcf478db 100644 --- a/pep-0201.txt +++ b/pep-0201.txt @@ -233,7 +233,7 @@ Subsequent Change to zip() date, rain, high, low = zip(*csv.reader(file("weather.csv"))) rearranges columnar data so that each field is collected into - individual tuples for straight-forward looping and summarization: + individual tuples for straightforward looping and summarization: print "Total rainfall", sum(rain) diff --git a/pep-0204.txt b/pep-0204.txt index 65e543906d7..186be9885d5 100644 --- a/pep-0204.txt +++ b/pep-0204.txt @@ -274,7 +274,7 @@ Rejection proposal altogether. The new syntax and its intentions were deemed not obvious enough. - [ TBD: Guido, ammend/confirm this, please. Preferably both; this + [ TBD: Guido, amend/confirm this, please. Preferably both; this is a PEP, it should contain *all* the reasons for rejection and/or reconsideration, for future reference. ] diff --git a/pep-0205.txt b/pep-0205.txt index 13c8b2bae7b..42a9c494031 100644 --- a/pep-0205.txt +++ b/pep-0205.txt @@ -123,7 +123,7 @@ Aspects of the Solution Space operations on the referents and catching some special exception raised when an invalid weak reference is used. - However, a number of users favor the proxy appoach simply because + However, a number of users favor the proxy approach simply because the weak reference looks so much like the original object. @@ -422,7 +422,7 @@ Appendix -- Dianne Hackborn's vref proposal (1995) return a type error, until they can be fixed. Finally, there are some other additional capabilities that this - system could provide. One that seems particularily interesting to + system could provide. One that seems particularly interesting to me involves allowing the Python programmer to add "destructor" function to a vref -- this Python function would be called immediately prior to the referenced object being deallocated, diff --git a/pep-0209.txt b/pep-0209.txt index c7e41970446..1c08f922179 100644 --- a/pep-0209.txt +++ b/pep-0209.txt @@ -113,7 +113,7 @@ Proposal d. Record access In some fields of science, data is stored in files as binary - records. For example in astronomy, photon data is stored as a + records. For example, in astronomy, photon data is stored as a 1 dimensional list of photons in order of arrival time. These records or C-like structures contain information about the detected photon, such as its arrival time, its position on the @@ -415,14 +415,14 @@ Open Issues 3. How is scalar coercion implemented? Python has fewer numeric types than Numeric which can cause - coercion problems. For example when multiplying a Python scalar + coercion problems. For example, when multiplying a Python scalar of type float and a Numeric array of type float, the Numeric array is converted to a double, since the Python float type is actually a double. This is often not the desired behavior, since the Numeric array will be doubled in size which is likely to be annoying, particularly for very large arrays. We prefer that the array type trumps the python type for the same type class, namely - integer, float, and complex. Therefore an operation between a + integer, float, and complex. Therefore, an operation between a Python integer and an Int16 (short) array will return an Int16 array. Whereas an operation between a Python float and an Int16 array would return a Float64 (double) array. Operations between @@ -444,7 +444,7 @@ Open Issues There are two approaches to implementing records depending on your point-of-view. The first is two divide arrays into separate - classes depending on the behavior of their types. For example + classes depending on the behavior of their types. For example, numeric arrays are one class, strings a second, and records a third, because the range and type of operations of each class differ. As such, a record array is not a new type, but a diff --git a/pep-0213.txt b/pep-0213.txt index f8361385a30..0bb5327398b 100644 --- a/pep-0213.txt +++ b/pep-0213.txt @@ -15,7 +15,7 @@ Introduction It is possible (and even relatively common) in Python code and in extension modules to "trap" when an instance's client code attempts to set an attribute and execute code instead. In other - words it is possible to allow users to use attribute assignment/ + words, it is possible to allow users to use attribute assignment/ retrieval/deletion syntax even though the underlying implementation is doing some computation rather than directly modifying a binding. diff --git a/pep-0216.txt b/pep-0216.txt index 9233e6cbd51..948bb4c8850 100644 --- a/pep-0216.txt +++ b/pep-0216.txt @@ -52,8 +52,8 @@ Python Docstring Goals a bit problematic, sometimes: for example, some are reluctant to have too long docstrings, because they do not want to take much space in the runtime. In addition, because of the current lack of tools, people - read objects' docstrings by "print"ing them, so a tendancy to make them - brief and free of markups has sprung up. This tendancy hinders writing + read objects' docstrings by "print"ing them, so a tendency to make them + brief and free of markups has sprung up. This tendency hinders writing better documentation-extraction tools, since it causes docstrings to contain little information, which is hard to parse. diff --git a/pep-0217.txt b/pep-0217.txt index 89ca659ea9d..908af681f0d 100644 --- a/pep-0217.txt +++ b/pep-0217.txt @@ -48,7 +48,7 @@ Solution Jython Issues - The method Py.printResult will be similarily changed. + The method Py.printResult will be similarly changed. Local Variables: diff --git a/pep-0219.txt b/pep-0219.txt index 2d9cffba632..0206ff10468 100644 --- a/pep-0219.txt +++ b/pep-0219.txt @@ -53,7 +53,7 @@ Background coroutines and microthreads can be implemented in Python in a way that involves almost no overhead. This PEP, therefor, offers a way for making Python able to realistically manage thousands of - separate "threads" of activity (vs. todays limit of perhaps dozens + separate "threads" of activity (vs. today's limit of perhaps dozens of separate threads of activity). Another justification for this PEP (explored in PEP 220) is that diff --git a/pep-0221.txt b/pep-0221.txt index 323cff853bf..92389a2090f 100644 --- a/pep-0221.txt +++ b/pep-0221.txt @@ -21,7 +21,7 @@ Introduction Rationale - This PEP proposes an extention of Python syntax regarding the + This PEP proposes an extension of Python syntax regarding the `import' and `from import' statements. These statements load in a module, and either bind that module to a local name, or binds objects from that module to a local name. However, it is @@ -81,7 +81,7 @@ Implementation details `global' directives. The special case of `from module import *' remains a special case, - in that it cannot accomodate an `as' clause, and that no STORE + in that it cannot accommodate an `as' clause, and that no STORE opcodes are generated; the objects imported are loaded directly into the local namespace. This also means that names imported in this fashion are always local, and do not follow the `global' @@ -91,7 +91,7 @@ Implementation details generalize the expression given after the `as' clause. Rather than a single name, it could be allowed to be any expression that yields a valid l-value; anything that can be assigned to. The - change to accomodate this is minimal, as the patch[2] proves, and + change to accommodate this is minimal, as the patch[2] proves, and the resulting generalization allows a number of new constructs that run completely parallel with other Python assignment constructs. However, this idea has been rejected by Guido, as diff --git a/pep-0225.txt b/pep-0225.txt index a1bb4eed29a..f2dd9f01fbb 100644 --- a/pep-0225.txt +++ b/pep-0225.txt @@ -375,7 +375,7 @@ Semantics of new operators - whatever the decision is taken, codes using existing interfaces should not be broken for a very long time. - Therefore not much is lost, and much flexibility retained, if the + Therefore, not much is lost, and much flexibility retained, if the semantic flavors of these two sets of operators are not dictated by the core language. The application packages are responsible for making the most suitable choice. This is already the case for @@ -502,7 +502,7 @@ Miscellaneous issues: a = b.i(1,2,-1,-2) * c.i(4,-2,3,-1) # a_ijkl = b_ijmn c_lnkm - Therefore one objectwise multiplication is sufficient. + Therefore, one objectwise multiplication is sufficient. - Bitwise operators. @@ -723,7 +723,7 @@ Credits and archives http://www.python.org/pipermail/python-list/2000-July/ http://www.python.org/pipermail/python-list/2000-August/ - The names of contributers are too numerous to mention here, + The names of contributors are too numerous to mention here, suffice to say that a large proportion of ideas discussed here are not our own. diff --git a/pep-0231.txt b/pep-0231.txt index b9fb302f483..70941d511ce 100644 --- a/pep-0231.txt +++ b/pep-0231.txt @@ -332,7 +332,7 @@ Examples assert c.a is not a - # no acquisiton on _ names + # no acquisition on _ names class E(Implicit): _color = 'purple' diff --git a/pep-0240.txt b/pep-0240.txt index 4f750151ade..5b8fdcd47ea 100644 --- a/pep-0240.txt +++ b/pep-0240.txt @@ -31,7 +31,7 @@ Rationale Rational numbers are useful for exact and unsurprising arithmetic. They give the correct results people have been taught in various math classes. Making the "obvious" non-integer type one with more - predictable semantics will surprise new programmers less then + predictable semantics will surprise new programmers less than using floating point numbers. As quite a few posts on c.l.py and on tutor@python.org have shown, people often get bit by strange semantics of floating point numbers: for example, round(0.98, 2) diff --git a/pep-0245.txt b/pep-0245.txt index bef3db89082..59281130e3e 100644 --- a/pep-0245.txt +++ b/pep-0245.txt @@ -60,7 +60,7 @@ The Problem based on implementation introspection, but often that also fails. For example, defining __getitem__ implies both a sequence and a mapping (the former with sequential, integer - keys). There is no way for the developer to be explict about + keys). There is no way for the developer to be explicit about which protocols the object intends to implement. - Python is limited, from the developer's point of view, by the @@ -74,10 +74,10 @@ The Problem - Python's dynamic typing is very flexible and powerful, but it does not have the advantage of static typed languages that - provide type checking. Static typed langauges provide you with - much more type saftey, but are often overly verbose because + provide type checking. Static typed languages provide you with + much more type safety, but are often overly verbose because objects can only be generalized by common subclassing and used - specificly with casting (for example, in Java). + specifically with casting (for example, in Java). There are also a number of documentation problems that interfaces try to solve. @@ -319,7 +319,7 @@ Interface Assertion Formal Interface Syntax - Python syntax is defined in a modified BNF grammer notation + Python syntax is defined in a modified BNF grammar notation described in the Python Reference Manual [8]. This section describes the proposed interface syntax using this grammar: diff --git a/pep-0247.txt b/pep-0247.txt index 29afad62eb0..8633dc1e936 100644 --- a/pep-0247.txt +++ b/pep-0247.txt @@ -68,7 +68,7 @@ Specification hashing object, measured in bytes. If the hash has a variable output size, this output size must be chosen when the hashing object is created, and this attribute must contain the - selected size. Therefore None is *not* a legal value for this + selected size. Therefore, None is *not* a legal value for this attribute. diff --git a/pep-0249.txt b/pep-0249.txt index 1d2da3953f4..77af979140b 100644 --- a/pep-0249.txt +++ b/pep-0249.txt @@ -944,7 +944,7 @@ render execution impossible. For these cases and in order to simplify error handling when dealing with databases, database module authors may choose to implement user -defineable error handlers. This section describes a standard way of +definable error handlers. This section describes a standard way of defining these error handlers. .. _Connection.errorhandler: diff --git a/pep-0255.txt b/pep-0255.txt index 87d0e3a2c92..ff8851a38ff 100644 --- a/pep-0255.txt +++ b/pep-0255.txt @@ -198,7 +198,7 @@ Specification: Return function return, executing the appropriate finally clauses (if any exist). Then a StopIteration exception is raised, signalling that the iterator is exhausted. A StopIteration exception is also raised if - control flows off the end of the generator without an explict return. + control flows off the end of the generator without an explicit return. Note that return means "I'm done, and have nothing interesting to return", for both generator functions and non-generator functions. @@ -377,7 +377,7 @@ Q & A yield is a control construct. It's also believed that efficient implementation in Jython requires that the compiler be able to determine potential suspension points at compile-time, and a new - keyword makes that easy. The CPython referrence implementation also + keyword makes that easy. The CPython reference implementation also exploits it heavily, to detect which functions *are* generator- functions (although a new keyword in place of "def" would solve that for CPython -- but people asking the "why a new keyword?" question diff --git a/pep-0258.txt b/pep-0258.txt index 000d561790d..a48ac86fc3c 100644 --- a/pep-0258.txt +++ b/pep-0258.txt @@ -206,7 +206,7 @@ the Reader has finished processing, the Publisher_ calls and all default transforms are stored. Each transform is a class in a module in the ``docutils/transforms/`` -package, a subclass of ``docutils.tranforms.Transform``. Transform +package, a subclass of ``docutils.transforms.Transform``. Transform classes each have a ``default_priority`` attribute which is used by the Transformer to apply transforms in order (low to high). The default priority can be overridden when adding transforms to the diff --git a/pep-0259.txt b/pep-0259.txt index 165dc2ef99d..fb9c5635acd 100644 --- a/pep-0259.txt +++ b/pep-0259.txt @@ -116,7 +116,7 @@ Rejected this idea any further. Frequently heard arguments against included: - - It it likely to break thousands of CGI scripts. + - It is likely to break thousands of CGI scripts. - Enough magic already (also: no more tinkering with 'print' please). diff --git a/pep-0261.txt b/pep-0261.txt index a0928353da5..d61c69a5156 100644 --- a/pep-0261.txt +++ b/pep-0261.txt @@ -109,7 +109,7 @@ Proposed Solution Surrogates could be easily created this way but the user still needs to be careful about slicing, indexing, printing - etc. Therefore some have suggested that Unicode + etc. Therefore, some have suggested that Unicode literals should not support surrogates. diff --git a/pep-0268.txt b/pep-0268.txt index b3591d46e93..a27d7e5178e 100644 --- a/pep-0268.txt +++ b/pep-0268.txt @@ -128,7 +128,7 @@ authentication scheme is typically set up hierarchically: the credentials for ``/path`` can be tried for ``/path/subpath``. The Digest authentication scheme has explicit support for the hierarchical setup. The ``httpx.Credentials`` object will store credentials for -multiple protection spaces, and can be looked up in two differents +multiple protection spaces, and can be looked up in two different ways: 1. looked up using ``(host, port, path)`` -- this lookup scheme is diff --git a/pep-0273.txt b/pep-0273.txt index e70274d62ba..4c3ff3b5bd0 100644 --- a/pep-0273.txt +++ b/pep-0273.txt @@ -190,11 +190,11 @@ Custom Imports Implementation A C implementation is available as SourceForge patch 492105. - Superceded by patch 652586 and current CVS. + Superseded by patch 652586 and current CVS. http://python.org/sf/492105 A newer version (updated for recent CVS by Paul Moore) is 645650. - Superceded by patch 652586 and current CVS. + Superseded by patch 652586 and current CVS. http://python.org/sf/645650 A competing implementation by Just van Rossum is 652586, which is diff --git a/pep-0275.txt b/pep-0275.txt index c839407c81e..996adb215e0 100644 --- a/pep-0275.txt +++ b/pep-0275.txt @@ -178,7 +178,7 @@ Solution 2: Adding a switch statement to Python else: print "D'oh!" - into (ommitting POP_TOP's and SET_LINENO's): + into (omitting POP_TOP's and SET_LINENO's): 6 LOAD_FAST 0 (x) 9 LOAD_CONST 1 (switch-table-1) @@ -218,7 +218,7 @@ Solution 2: Adding a switch statement to Python behaviour (as does the switch statement in C). Each case defines a complete and independent suite; much like in a if-elif-else statement. This also enables using break in - switch statments inside loops. + switch statements inside loops. If the interpreter finds that the switch variable x is not hashable, it should raise a TypeError at run-time diff --git a/pep-0276.txt b/pep-0276.txt index 3072f8693c2..6504ae5343d 100644 --- a/pep-0276.txt +++ b/pep-0276.txt @@ -320,7 +320,7 @@ Issues: issue by using a variation of what is outlined in the specification section of this proposal. Instead of adding an __iter__ method to class int, change the for-loop handling - code to convert (in essense) from + code to convert (in essence) from for i in n: # when isinstance(n,int) is 1 @@ -384,14 +384,14 @@ Issues: - and more. It should be noted that there was much debate but not an - overwhelming concensus for any of these larger-scale suggestions. + overwhelming consensus for any of these larger-scale suggestions. Clearly, PEP 276 does not propose such a large-scale change and instead focuses on a specific problem area. Towards the end of the discussion period, several posters expressed favor for the narrow focus and simplicity of PEP 276 vis-a-vis the more ambitious suggestions that were advanced. There did appear to be - concensus for the need for a PEP for any such larger-scale, + consensus for the need for a PEP for any such larger-scale, alternative suggestion. In light of this recognition, details of the various alternative suggestions are not discussed here further. diff --git a/pep-0278.txt b/pep-0278.txt index 4f58ce191af..5863965c175 100644 --- a/pep-0278.txt +++ b/pep-0278.txt @@ -164,7 +164,7 @@ Rationale Universal newline support can be disabled during configure because it does have a small performance penalty, and moreover the implementation has - not been tested on all concievable platforms yet. It might also be silly + not been tested on all conceivable platforms yet. It might also be silly on some platforms (WinCE or Palm devices, for instance). If universal newline support is not enabled then file objects do not have the "newlines" attribute, so testing whether the current Python has it can be done with a diff --git a/pep-0285.txt b/pep-0285.txt index 72169a1d95d..39bd78a14b5 100644 --- a/pep-0285.txt +++ b/pep-0285.txt @@ -124,7 +124,7 @@ Review 8) Should we strive to require that Boolean operations (like "if", "and", "not") have a bool as an argument in the future, so that for example "if []:" would become illegal and would have to be - writen as "if bool([]):" ??? + written as "if bool([]):" ??? => No!!! diff --git a/pep-0289.txt b/pep-0289.txt index a8f0cf26df2..3a3dba9116a 100644 --- a/pep-0289.txt +++ b/pep-0289.txt @@ -22,7 +22,7 @@ generators [2]_. Rationale ========= -Experience with list comprehensions has shown their wide-spread +Experience with list comprehensions has shown their widespread utility throughout Python. However, many of the use cases do not need to have a full list created in memory. Instead, they only need to iterate over the elements one at a time. diff --git a/pep-0290.txt b/pep-0290.txt index efb3c1bc918..07451b61a23 100644 --- a/pep-0290.txt +++ b/pep-0290.txt @@ -88,7 +88,7 @@ comprehension should be changed to read:: return [[int(i==j) for i in range(m)] for j in range(m)] -There are similiar concerns when storing data to be used by other +There are similar concerns when storing data to be used by other applications which may expect a number instead of True or False. diff --git a/pep-0293.txt b/pep-0293.txt index e97fc01b9d5..ef8caf4bed2 100644 --- a/pep-0293.txt +++ b/pep-0293.txt @@ -114,7 +114,7 @@ Specification Should further encoding errors occur, the encoder is allowed to reuse the exception object for the next call to the callback. - Furthermore the encoder is allowed to cache the result of + Furthermore, the encoder is allowed to cache the result of codecs.lookup_error. If the callback does not know how to handle the exception, it must @@ -250,8 +250,8 @@ Rationale This slows down encoding dramatically as now the loop through the string is done in Python code and no longer in C code. - Furthermore this solution poses problems with stateful encodings. - For example UTF-16 uses a Byte Order Mark at the start of the + Furthermore, this solution poses problems with stateful encodings. + For example, UTF-16 uses a Byte Order Mark at the start of the encoded byte string to specify the byte order. Using (2) with UTF-16, results in an 8 bit string with a BOM between every character. diff --git a/pep-0295.txt b/pep-0295.txt index 5441a9b6eea..34cf7ab1267 100644 --- a/pep-0295.txt +++ b/pep-0295.txt @@ -47,7 +47,7 @@ Rationale - ignore the first character after opening quotation, if it is newline - second: ignore in string constants all spaces and tabs up to - first non-whitespace character, but no more then current + first non-whitespace character, but no more than current indentation. After applying this, previous program will print: diff --git a/pep-0296.txt b/pep-0296.txt index de4eca30a48..e9e3d5ca0f6 100644 --- a/pep-0296.txt +++ b/pep-0296.txt @@ -262,7 +262,7 @@ Contrast to existing types solve a wider class of problems. Finally, any third party extension can not implement pickling without - creating a temporary object of a standard python type. For example in the + creating a temporary object of a standard Python type. For example, in the Numeric community, it is unpleasant that a large array can't pickle without creating a large binary string to duplicate the array data. diff --git a/pep-0298.txt b/pep-0298.txt index b9608d911a1..ce74d173be1 100644 --- a/pep-0298.txt +++ b/pep-0298.txt @@ -182,7 +182,7 @@ Additional Notes/Comments the counter is zero when the object is deleted -- if the assert fails, someone DECREF'ed their reference to the object without releasing it. (The rule should be that you must own a - reference to the object while you've aquired the object.) + reference to the object while you've acquired the object.) For strings that might be impractical because the string object would have to grow 4 bytes to hold the counter; but the diff --git a/pep-0302.txt b/pep-0302.txt index bf34daaef4f..a73f03603be 100644 --- a/pep-0302.txt +++ b/pep-0302.txt @@ -13,7 +13,7 @@ Post-History: 19-Dec-2002 .. warning:: The language reference for import [10]_ and importlib documentation - [11]_ now supercede this PEP. This document is no longer updated + [11]_ now supersede this PEP. This document is no longer updated and provided for historical purposes only. @@ -180,7 +180,7 @@ The built-in ``__import__`` function (known as ``PyImport_ImportModuleEx()`` in ``import.c``) will then check to see whether the module doing the import is a package or a submodule of a package. If it is indeed a (submodule of a) package, it first tries to do the import relative to the package (the parent -package for a submodule). For example if a package named "spam" does "import +package for a submodule). For example, if a package named "spam" does "import eggs", it will first look for a module named "spam.eggs". If that fails, the import continues as an absolute import: it will look for a module named "eggs". Dotted name imports work pretty much the same: if package "spam" does diff --git a/pep-0305.txt b/pep-0305.txt index 093e6bebdbc..4d4694b34ef 100644 --- a/pep-0305.txt +++ b/pep-0305.txt @@ -63,11 +63,11 @@ Rationale Often, CSV files are formatted simply enough that you can get by reading them line-by-line and splitting on the commas which delimit the fields. This is especially true if all the data being read is -numeric. This approach may work for awhile, then come back to bite +numeric. This approach may work for a while, then come back to bite you in the butt when somebody puts something unexpected in the data like a comma. As you dig into the problem you may eventually come to the conclusion that you can solve the problem using regular -expressions. This will work for awhile, then break mysteriously one +expressions. This will work for a while, then break mysteriously one day. The problem grows, so you dig deeper and eventually realize that you need a purpose-built parser for the format. diff --git a/pep-0307.txt b/pep-0307.txt index 31767a0bf9c..e8e70b963a9 100644 --- a/pep-0307.txt +++ b/pep-0307.txt @@ -614,7 +614,7 @@ The extension registry has to be unpickled. (The same issue already exists for direct references to such names in pickles that use protocols 0 or 1.) - Here is the proposed initial assigment of extension code ranges: + Here is the proposed initial assignment of extension code ranges: First Last Count Purpose diff --git a/pep-0308.txt b/pep-0308.txt index 27b5766fd17..75e92c0f28e 100644 --- a/pep-0308.txt +++ b/pep-0308.txt @@ -15,7 +15,7 @@ Adding a conditional expression On 9/29/2005, Guido decided to add conditional expressions in the form of "X if C else Y". [1] - The motivating use case was the prevalance of error-prone attempts + The motivating use case was the prevalence of error-prone attempts to achieve the same effect using "and" and "or". [2] Previous community efforts to add a conditional expression were @@ -302,7 +302,7 @@ Short-Circuit Behavior show that its ternary operator used very rarely (as a percentage of lines of code). - A counter point to that analysis is that the availability of a + A counterpoint to that analysis is that the availability of a ternary operator helped the programmer in every case because it spared the need to search for side-effects. Further, it would preclude errors arising from distant modifications which introduce diff --git a/pep-0312.txt b/pep-0312.txt index 1650c357f0f..82a93b55090 100644 --- a/pep-0312.txt +++ b/pep-0312.txt @@ -27,7 +27,7 @@ Deferral propositions which have no chance at all. The examples section is good and highlights the readability improvements. It would carry more weight with additional examples and with real-world - referrents (instead of the abstracted dummy calls to :A and :B). + referents (instead of the abstracted dummy calls to :A and :B). Motivation diff --git a/pep-0313.txt b/pep-0313.txt index b5c64136dba..bc7114021f9 100644 --- a/pep-0313.txt +++ b/pep-0313.txt @@ -35,7 +35,7 @@ Rationale Roman numerals are used in a number of areas, and adding them to Python as literals would make computations in those areas easier. - For instance, Superbowls are counted with Roman numerals, and many + For instance, Super Bowls are counted with Roman numerals, and many older movies have copyright dates in Roman numerals. Further, LISP provides a Roman numerals literal package, so adding Roman numerals to Python will help ease the LISP-envy sometimes seen in diff --git a/pep-0318.txt b/pep-0318.txt index 32eb6a7e239..2a8f7a94fe8 100644 --- a/pep-0318.txt +++ b/pep-0318.txt @@ -149,7 +149,7 @@ a list of proposals to `EuroPython 2004`_, where a discussion took place. Subsequent to this, he decided that we'd have the `Java-style`_ @decorator syntax, and this appeared for the first time in 2.4a2. Barry Warsaw named this the 'pie-decorator' syntax, in honor of the -Pie-thon Parrot shootout which was occured around the same time as +Pie-thon Parrot shootout which occurred around the same time as the decorator syntax, and because the @ looks a little like a pie. Guido `outlined his case`_ on Python-dev, including `this piece`_ on some of the (many) rejected forms. diff --git a/pep-0319.txt b/pep-0319.txt index 83160f2e27a..148c199ae7c 100644 --- a/pep-0319.txt +++ b/pep-0319.txt @@ -404,10 +404,10 @@ PEP 310 Reliable Acquisition/Release Pairs proposes that unqualified 'synchronize' statements synchronize on a global, internal, transparent lock in addition to qualifiled 'synchronize' statements. The 'with' statement also requires lock - initialization, while the 'synchronize' statment can synchronize + initialization, while the 'synchronize' statement can synchronize on any target object *including* locks. - While limited in this fashion, the 'with' statment is more + While limited in this fashion, the 'with' statement is more abstract and serves more purposes than synchronization. For example, transactions could be used with the 'with' keyword: @@ -431,7 +431,7 @@ How Java Does It synchronized (Expression) Block - Expression must yeild a valid object (null raises an error and + Expression must yield a valid object (null raises an error and exceptions during 'Expression' terminate the 'synchronized' block for the same reason) upon which 'Block' is synchronized. diff --git a/pep-0323.txt b/pep-0323.txt index d463c6b14b5..9e0ff9edb7a 100644 --- a/pep-0323.txt +++ b/pep-0323.txt @@ -408,7 +408,7 @@ Rationale the accidental (rather than deliberate) copying performed by copy.copy shares, rather than duplicating the "index" list, which is the mutable attribute it.indx (a list of numerical indices). - Thus, this "client code" of the iterator, which attemps to iterate + Thus, this "client code" of the iterator, which attempts to iterate twice over a portion of the sequence via a copy.copy on the iterator, is NOT correct. diff --git a/pep-0325.txt b/pep-0325.txt index 04b74b74ee9..a00b8b4012b 100644 --- a/pep-0325.txt +++ b/pep-0325.txt @@ -162,7 +162,7 @@ Possible Semantics A - Return Semantics: The generator should be resumed, generator execution should continue as if the instruction at the re-entry - point is a return. Consequently finally clauses surrounding the + point is a return. Consequently, finally clauses surrounding the re-entry point would be executed, in the case of a then allowed try-yield-finally pattern. @@ -210,7 +210,7 @@ Possible Semantics The exception approach has the advantage to let the generator distinguish between termination cases and have more control. On - the other hand clear-cut semantics seem harder to define. + the other hand, clear-cut semantics seem harder to define. Remarks diff --git a/pep-0327.txt b/pep-0327.txt index ed1ffa1b779..d56195fc6fe 100644 --- a/pep-0327.txt +++ b/pep-0327.txt @@ -351,7 +351,7 @@ Edward Loper give us an example of when the limits are to be crossed: probabilities. That said, Robert Brewer and Andrew Lentvorski want the limits to be -easily modifiable by the users. Actually, this is quite posible:: +easily modifiable by the users. Actually, this is quite possible:: >>> d1 = Decimal("1e999999999") # at the exponent limit >>> d1 @@ -859,7 +859,7 @@ Regarding str() and repr() behaviour, Ka-Ping Yee proposes that repr() have the same behaviour as str() and Tim Peters proposes that str() behave like the to-scientific-string operation from the Spec. -This is posible, because (from Aahz): "The string form already +This is possible, because (from Aahz): "The string form already contains all the necessary information to reconstruct a Decimal object". diff --git a/pep-0333.txt b/pep-0333.txt index 5e4f2f20f7e..93f20ebb0f3 100644 --- a/pep-0333.txt +++ b/pep-0333.txt @@ -319,7 +319,7 @@ are more stringent than for a "pure" server or application, and these points will be noted in the specification. Here is a (tongue-in-cheek) example of a middleware component that -converts ``text/plain`` responses to pig latin, using Joe Strout's +converts ``text/plain`` responses to pig Latin, using Joe Strout's ``piglatin.py``. (Note: a "real" middleware component would probably use a more robust way of checking the content type, and should also check for a content encoding. Also, this simple @@ -1450,7 +1450,7 @@ Questions and Answers chooses *not* to use a dictionary, then there will be interoperability problems despite that server's "conformance" to spec. Therefore, making a dictionary mandatory simplifies the - specification and guarantees interoperabilty. + specification and guarantees interoperability. Note that this does not prevent server or framework developers from offering specialized services as custom variables *inside* the diff --git a/pep-0334.txt b/pep-0334.txt index d2bcc0d453a..1d8fa73a1db 100644 --- a/pep-0334.txt +++ b/pep-0334.txt @@ -282,7 +282,7 @@ corresponding iterator would look like if coded up as a class:: Complicating Factors -------------------- -While the above example is straight-forward, things are a bit more +While the above example is straightforward, things are a bit more complicated if the intermediate generator 'condenses' values, that is, it pulls in two or more values for each value it produces. For example, :: diff --git a/pep-0339.txt b/pep-0339.txt index 561602632d5..5bae2b22ab7 100644 --- a/pep-0339.txt +++ b/pep-0339.txt @@ -46,7 +46,7 @@ to read some source to have an exact understanding of all details. Parse Trees ----------- -Python's parser is an LL(1) parser mostly based off of the +Python's parser is an LL(1) parser mostly based on the implementation laid out in the Dragon Book [Aho86]_. The grammar file for Python can be found in Grammar/Grammar with the diff --git a/pep-0343.txt b/pep-0343.txt index efb8879959f..1e50dda12ad 100644 --- a/pep-0343.txt +++ b/pep-0343.txt @@ -887,7 +887,7 @@ Reference Implementation The __context__() method will be removed in Python 2.5a3 -Ackowledgements +Acknowledgements Many people contributed to the ideas and concepts in this PEP, including all those mentioned in the acknowledgements for PEP 340 diff --git a/pep-0344.txt b/pep-0344.txt index 82ce01dca80..ba2f863d62f 100644 --- a/pep-0344.txt +++ b/pep-0344.txt @@ -61,9 +61,9 @@ History exception with more information. Brett Cannon [2] brought up chained exceptions again in June 2003, prompting a long discussion. - Greg Ewing [3] identified the case of an exception occuring in a + Greg Ewing [3] identified the case of an exception occurring in a 'finally' block during unwinding triggered by an original exception, - as distinct from the case of an exception occuring in an 'except' + as distinct from the case of an exception occurring in an 'except' block that is handling the original exception. Greg Ewing [4] and Guido van Rossum [5], and probably others, have diff --git a/pep-0345.txt b/pep-0345.txt index d6a92a84fd1..1f14793f11e 100644 --- a/pep-0345.txt +++ b/pep-0345.txt @@ -143,7 +143,7 @@ Example:: | 3 | -This encoding implies that any occurences of a CRLF followed by 7 spaces +This encoding implies that any occurrences of a CRLF followed by 7 spaces and a pipe char have to be replaced by a single CRLF when the field is unfolded using a RFC822 reader. @@ -409,7 +409,7 @@ The comma (",") is equivalent to the **and** operator. Each version number must be in the format specified in PEP 386. When a version is provided, it always includes all versions that -starts with the same value. For example the "2.5" version of Python +starts with the same value. For example, the "2.5" version of Python will include versions like "2.5.2" or "2.5.3". Pre and post releases in that case are excluded. So in our example, versions like "2.5a1" are not included when "2.5" is used. If the first version of the range is diff --git a/pep-0346.txt b/pep-0346.txt index 56e5e986795..000e9dabc11 100644 --- a/pep-0346.txt +++ b/pep-0346.txt @@ -1216,7 +1216,7 @@ iterator's ``__finish__()`` method from the ``for`` loop:: return self.itr.next() Secondly, an appropriate statement template is needed to ensure the -the iterator is finished eventually:: +iterator is finished eventually:: @statement_template def finishing(iterable): diff --git a/pep-0348.txt b/pep-0348.txt index 5deac8a34ad..92d0cbe3e7c 100644 --- a/pep-0348.txt +++ b/pep-0348.txt @@ -372,7 +372,7 @@ that the exception is already used throughout the interpreter [#python-dev6]_. Rejection of SimpleError was founded on the thought that people should be free to use whatever exception they choose and not have one -so blatently suggested [#python-dev7]_. +so blatantly suggested [#python-dev7]_. Renaming Existing Exceptions ---------------------------- diff --git a/pep-0357.txt b/pep-0357.txt index 6253ce67d78..ca3505479f8 100644 --- a/pep-0357.txt +++ b/pep-0357.txt @@ -102,7 +102,7 @@ Specification: happens if the integer returned from nb_index cannot fit into a Py_ssize_t value. - If exc is NULL, then the returnd value will be clipped to + If exc is NULL, then the returned value will be clipped to PY_SSIZE_T_MAX or PY_SSIZE_T_MIN depending on whether the nb_index slot of obj returned a positive or negative integer. If exc is non-NULL, then it is the error object @@ -119,7 +119,7 @@ Implementation Plan create the __index__ method 2) Change the ISINT macro in ceval.c to ISINDEX and alter it to - accomodate objects with the index slot defined. + accommodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accommodate objects with the index slot defined. @@ -175,7 +175,7 @@ Discussion Questions Why return PyObject * from nb_index? - Intially Py_ssize_t was selected as the return type for the + Initially Py_ssize_t was selected as the return type for the nb_index slot. However, this led to an inability to track and distinguish overflow and underflow errors without ugly and brittle hacks. As the nb_index slot is used in at least 3 different ways diff --git a/pep-0358.txt b/pep-0358.txt index 7ce989769d6..44f6859f080 100644 --- a/pep-0358.txt +++ b/pep-0358.txt @@ -19,8 +19,8 @@ Update Abstract This PEP outlines the introduction of a raw bytes sequence type. - Adding the bytes type is one step in the transition to Unicode - based str objects which will be introduced in Python 3.0. + Adding the bytes type is one step in the transition to + Unicode-based str objects which will be introduced in Python 3.0. The PEP describes how the bytes type should work in Python 2.6, as well as how it should work in Python 3.0. (Occasionally there are diff --git a/pep-0368.txt b/pep-0368.txt index 0e4455f26bc..82b030a817d 100644 --- a/pep-0368.txt +++ b/pep-0368.txt @@ -53,7 +53,7 @@ Rationale A good way to have high quality modules ready for inclusion in the Python standard library is to simply wait for natural selection among competing external libraries to provide a clear winner with useful -functionality and a big user base. Then the de-facto standard can be +functionality and a big user base. Then the de facto standard can be officially sanctioned by including it in the standard library. Unfortunately this approach hasn't worked well for the creation of a diff --git a/pep-0369.txt b/pep-0369.txt index 5529b7d045a..dfbd606f09f 100644 --- a/pep-0369.txt +++ b/pep-0369.txt @@ -103,7 +103,7 @@ hooks for the newly loaded module. If hooks are found then the hooks are called in the order they were registered with the module instance as first argument. The processing of the hooks is stopped when a method raises an exception. At the end the entry for the module name set to None, even -when an error has occured. +when an error has occurred. Additionally the new ``__notified__`` slot of the module object is set to ``True`` in order to prevent infinity recursions when the notification @@ -127,7 +127,7 @@ The hook is fired immediately. Invariants ---------- -The import hook system guarentees certain invariants. XXX +The import hook system guarantees certain invariants. XXX Sample Python implementation @@ -166,7 +166,7 @@ New C API functions ``PyObject* PyImport_NotifyLoadedByModule(PyObject *module)`` Notify the post import system that a module was requested. Returns the a borrowed reference to the same module object or NULL if an error has - occured. The function calls only the hooks for the module itself and not + occurred. The function calls only the hooks for the module itself and not its parents. The function must be called with the import lock acquired. ``PyObject* PyImport_NotifyLoadedByName(const char *name)`` diff --git a/pep-0370.txt b/pep-0370.txt index 7ca43ba0925..02109add425 100644 --- a/pep-0370.txt +++ b/pep-0370.txt @@ -96,7 +96,7 @@ Windows Notes On Windows the *Application Data* directory (aka ``APPDATA``) was chosen because it is the most designated place for application data. Microsoft -recommands that software doesn't write to ``USERPROFILE`` [5]_ and +recommends that software doesn't write to ``USERPROFILE`` [5]_ and ``My Documents`` is not suited for application data, either. [8]_ The code doesn't query the Win32 API, instead it uses the environment variable %APPDATA%. @@ -106,7 +106,7 @@ with domain logins the application data may be copied from and to the a central server. This can slow down log-in and log-off. Users can keep the data on the server by e.g. setting PYTHONUSERBASE to the value "%HOMEDRIVE%%HOMEPATH%\Applicata Data". Users should consult their local -adminstrator for more information. [13]_ +administrator for more information. [13]_ Unix Notes diff --git a/pep-0374.txt b/pep-0374.txt index bf581397862..b05c2245501 100644 --- a/pep-0374.txt +++ b/pep-0374.txt @@ -1442,7 +1442,7 @@ While svn has served the development team well, it needs to be admitted that svn does not serve the needs of non-committers as well as a DVCS does. Because svn only provides its features such as version control, branching, etc. to people with commit privileges on the -repository it can be a hinderance for people who lack commit +repository it can be a hindrance for people who lack commit privileges. But DVCSs have no such limitiation as anyone can create a local branch of Python and perform their own local commits without the burden that comes with cloning the entire svn repository. Allowing diff --git a/pep-0379.txt b/pep-0379.txt index a355ce93a8b..b043776b37c 100644 --- a/pep-0379.txt +++ b/pep-0379.txt @@ -121,7 +121,7 @@ Examples from the Standard Library return inspect.cleandoc(node.body[0].value.s) return node.body[0].value.s - Using assignment expresion: + Using assignment expression: def get_docstring(node, clean=True): if not isinstance(node, (FunctionDef, ClassDef, Module)): diff --git a/pep-0380.txt b/pep-0380.txt index eeb9d91565e..4ea0b10b917 100644 --- a/pep-0380.txt +++ b/pep-0380.txt @@ -286,7 +286,7 @@ However, there are use cases for this as well, where the thread is seen as a producer or consumer of items. The ``yield from`` expression allows the logic of the thread to be spread over as many functions as desired, with the production or consumption of items -occuring in any subfunction, and the items are automatically routed to +occurring in any subfunction, and the items are automatically routed to or from their ultimate source or destination. Concerning ``throw()`` and ``close()``, it is reasonable to expect diff --git a/pep-0381.txt b/pep-0381.txt index 5c910a04348..e7387bb80ea 100644 --- a/pep-0381.txt +++ b/pep-0381.txt @@ -194,7 +194,7 @@ The content will look like this:: The counting starts the day the mirror is launched, and there is one file per day, compressed using the `bzip2` format. Each file is named -like the day. For example `2008-11-06.bz2` is the file for the 6th of +like the day. For example, `2008-11-06.bz2` is the file for the 6th of November 2008. They are then provided in a folder called `days`. For example: @@ -217,7 +217,7 @@ relevant links, plus a small part about `User-Agent`. The mirroring protocol :::::::::::::::::::::: -Mirrors must reduce the amount of data transfered between the central +Mirrors must reduce the amount of data transferred between the central server and the mirror. To achieve that, they MUST use the changelog() PyPI XML-RPC call, and only refetch the packages that have been changed since the last time. For each package P, they MUST copy @@ -237,7 +237,7 @@ User-agent request header In order to be able to differentiate actions taken by clients over PyPI, a specific user agent name should be provided by all mirroring -softwares. +software. This is also true for all clients like: @@ -296,7 +296,7 @@ PyPI and Distutils protocols. In other words, the `register` and `upload` command should be compatible with any package index server out there. -Softwares that are compatible with PyPI and Distutils so far: +Software that are compatible with PyPI and Distutils so far: - PloneSoftwareCenter [#psc]_ wich is used to run plone.org products section. - EggBasket [#eggbasket]_. @@ -312,7 +312,7 @@ indexes, it should be able to use each one of them as a potential source of packages. Different indexes should be defined as a sorted list for the client to look for a package. -Each independant index can of course provide a list of its mirrors. +Each independent index can of course provide a list of its mirrors. XXX define how to get the hostname for the mirrors of an arbitrary index. diff --git a/pep-0382.txt b/pep-0382.txt index 96f3514b123..1c29572af7b 100644 --- a/pep-0382.txt +++ b/pep-0382.txt @@ -132,7 +132,7 @@ Impact on Import Hooks ---------------------- Both loaders and finders as defined in PEP 302 will need to be changed -to support namespace packages. Failure to comform to the protocol +to support namespace packages. Failure to conform to the protocol below might cause a package not being recognized as a namespace package; loaders and finders not supporting this protocol must raise AttributeError when the functions below get accessed. diff --git a/pep-0386.txt b/pep-0386.txt index 7966dcb650e..74625337abf 100644 --- a/pep-0386.txt +++ b/pep-0386.txt @@ -331,7 +331,7 @@ Some examples probably make it clearer:: The trailing ``.dev123`` is for pre-releases. The ``.post123`` is for post-releases -- which apparently are used by a number of projects out there -(e.g. Twisted [#twisted]_). For example *after* a ``1.2.0`` release there might +(e.g. Twisted [#twisted]_). For example, *after* a ``1.2.0`` release there might be a ``1.2.0-r678`` release. We used ``post`` instead of ``r`` because the ``r`` is ambiguous as to whether it indicates a pre- or post-release. diff --git a/pep-0387.txt b/pep-0387.txt index eb743d0e2fa..0dbec0be01d 100644 --- a/pep-0387.txt +++ b/pep-0387.txt @@ -20,7 +20,7 @@ Rationale ========= As one of the most used programming languages today [#tiobe]_, the Python core -language and its standard library play a critcal role in thousands of +language and its standard library play a critical role in thousands of applications and libraries. This is fantastic; it is probably one of a language designer's most wishful dreams. However, it means the development team must be very careful not to break this existing 3rd party code with new releases. @@ -47,7 +47,7 @@ This policy applies to all public APIs. These include: - Behavior of classes with regards to subclasses: the conditions under which overridden methods are called. -Others are explicity not part of the public API. They can change or +Others are explicitly not part of the public API. They can change or be removed at any time in any way. These include: - Function, class, module, attribute, method, and C-API names and types that diff --git a/pep-0390.txt b/pep-0390.txt index 3668d08c0c8..9a3c5a52b75 100644 --- a/pep-0390.txt +++ b/pep-0390.txt @@ -193,7 +193,7 @@ Let's run in on a ``Python 2.5 i386 Linux``:: >>> metadata.get_requires() ['foo', 'bar', 'baz'] -The execution environment can be overriden in case we want to get the meyadata +The execution environment can be overridden in case we want to get the metadata for another environment:: >>> env = {'python_version': '2.4', @@ -209,8 +209,8 @@ for another environment:: PEP 314 is changed accordingly, meaning that each field will be able to have that extra condition marker. -Compatiblity -============ +Compatibility +============= This change is based on a new metadata ``1.2`` format meaning that Distutils will be able to distinguish old PKG-INFO files from new ones. diff --git a/pep-0396.txt b/pep-0396.txt index 987f2707824..fb55ff729d2 100644 --- a/pep-0396.txt +++ b/pep-0396.txt @@ -71,7 +71,7 @@ Rationale Python modules, both in the standard library and available from third parties, have long included version numbers. There are established -de-facto standards for describing version numbers, and many ad-hoc +de facto standards for describing version numbers, and many ad-hoc ways have grown organically over the years. Often, version numbers can be retrieved from a module programmatically, by importing the module and inspecting an attribute. Classic Python distutils diff --git a/pep-0397.txt b/pep-0397.txt index 5c17b2e605f..7f0beb1627f 100644 --- a/pep-0397.txt +++ b/pep-0397.txt @@ -84,7 +84,7 @@ Installation with Python. The console launcher will be named 'py.exe' and the Windows one named 'pyw.exe'. The "windows" (ie., GUI) version of the launcher will attempt to locate and launch pythonw.exe even if a virtual shebang - line nominates simply "python" - infact, the trailing 'w' notation is + line nominates simply "python" - in fact, the trailing 'w' notation is not supported in the virtual shebang line at all. The launcher is installed into the Windows directory (see diff --git a/pep-0399.txt b/pep-0399.txt index d4bca27cf96..3fe730c984f 100644 --- a/pep-0399.txt +++ b/pep-0399.txt @@ -36,7 +36,7 @@ used in Java applications. A problem all of the VMs other than CPython face is handling modules from the standard library that are implemented (to some extent) in C. Since other VMs do not typically support the entire `C API of CPython`_ -they are unable to use the code used to create the module. Often times +they are unable to use the code used to create the module. Oftentimes this leads these other VMs to either re-implement the modules in pure Python or in the programming language used to implement the VM itself (e.g., in C# for IronPython). This duplication of effort between diff --git a/pep-0401.txt b/pep-0401.txt index 3e1adaf6ee8..dae6700067f 100644 --- a/pep-0401.txt +++ b/pep-0401.txt @@ -69,7 +69,7 @@ him: and sole next release. The Python 3.0 string and bytes types will be back ported to Python 2.6.2 for the convenience of developers. -* Recognized that C is a 20th century language with almost universal +* Recognized that C is a 20th-century language with almost universal rejection by programmers under the age of 30, the CPython implementation will terminate with the release of Python 2.6.2 and 3.0.2. Thereafter, the reference implementation of Python will diff --git a/pep-0406.txt b/pep-0406.txt index 9c3dae0d7ce..07d2fc1a1f8 100644 --- a/pep-0406.txt +++ b/pep-0406.txt @@ -113,7 +113,7 @@ The proposed extension consists of the following objects: Reimplementation of the builtin ``__import__()`` function. The import of a module will proceed using the state stored in the ImportEngine instance rather than the global import state. For full - documentation of ``__import__`` funtionality, see [2]_ . + documentation of ``__import__`` functionality, see [2]_ . ``__import__()`` from ``ImportEngine`` and its subclasses can be used to customise the behaviour of the ``import`` statement by replacing ``__builtin__.__import__`` with ``ImportEngine().__import__``. diff --git a/pep-0409.txt b/pep-0409.txt index 8814dcd1a38..f3e868a7bf0 100644 --- a/pep-0409.txt +++ b/pep-0409.txt @@ -105,7 +105,7 @@ were put forth on how to implement this at the language level: * Use one of the boolean values in ``__cause__``: ``False`` would be the default value, and would be replaced when ``from ...`` was used with the - explicity chained exception or ``None``. + explicitly chained exception or ``None``. Rejected as this encourages the use of two different objects types for ``__cause__`` with one of them (boolean) not allowed to have the full range diff --git a/pep-0412.txt b/pep-0412.txt index cd1996a1d7c..7e5560949fd 100644 --- a/pep-0412.txt +++ b/pep-0412.txt @@ -146,7 +146,7 @@ Change to data structures: Third party modules which meddle with the internals of the dictionary implementation will break. Changes to repr() output and iteration order: For most cases, this -will be unchanged. However for some split-table dictionaries the +will be unchanged. However, for some split-table dictionaries the iteration order will change. Neither of these cons should be a problem. Modules which meddle with diff --git a/pep-0413.txt b/pep-0413.txt index 9e26a3671e1..998bb7123f4 100644 --- a/pep-0413.txt +++ b/pep-0413.txt @@ -81,7 +81,7 @@ on the wider Python ecosystem. Under the current CPython release cycle, distributors of key binary extensions will often support Python releases even after the CPython branches enter "security fix only" mode (for example, Twisted currently ships binaries -for 2.5, 2.6 and 2.7, NumPy and SciPy suport those 3 along with 3.1 and 3.2, +for 2.5, 2.6 and 2.7, NumPy and SciPy support those 3 along with 3.1 and 3.2, PyGame adds a 2.4 binary release, wxPython provides both 32-bit and 64-bit binaries for 2.6 and 2.7, etc). diff --git a/pep-0418.txt b/pep-0418.txt index 6c1f9655796..fd0f4c9918b 100644 --- a/pep-0418.txt +++ b/pep-0418.txt @@ -999,7 +999,7 @@ is not subject to NTP adjustments. CLOCK_MONOTONIC_RAW requires Linux 2.6.28 or later. Linux 2.6.39 and glibc 2.14 introduces a new clock: CLOCK_BOOTTIME. -CLOCK_BOOTTIME is idential to CLOCK_MONOTONIC, except that it also +CLOCK_BOOTTIME is identical to CLOCK_MONOTONIC, except that it also includes any time spent in suspend. Read also `Waking systems from suspend `_ (March, 2011). @@ -1595,7 +1595,7 @@ Time: lists hardware clocks and time functions with their resolution and epoch or range * On Windows, the JavaScript runtime of Firefox interpolates - GetSystemTimeAsFileTime() with QueryPerformanceCounter() to get an + GetSystemTimeAsFileTime() with QueryPerformanceCounter() to get a higher resolution. See the `Bug 363258 - bad millisecond resolution for (new Date).getTime() / Date.now() on Windows `_. diff --git a/pep-0418/clockutils.py b/pep-0418/clockutils.py index 9aad79a4e0a..b5a2c8c1311 100644 --- a/pep-0418/clockutils.py +++ b/pep-0418/clockutils.py @@ -218,7 +218,7 @@ def now(self): class _NT_GetTickCount64(_Clock): ''' Based on http://msdn.microsoft.com/en-us/library/windows/desktop/ms724411%28v=vs.85%29.aspx - Note this this specificly disavows high resolution. + Note that this specifically disavows high resolution. ''' flags = RUNTIME|MONOTONIC resolution = 0.001 diff --git a/pep-0419.txt b/pep-0419.txt index 97ec8e3cc6f..ea26537796f 100644 --- a/pep-0419.txt +++ b/pep-0419.txt @@ -95,7 +95,7 @@ Bluelet [2]_, or Twisted [3]_. :: In the example above, ``yield something`` means to pause executing the current coroutine and to execute coroutine ``something`` until it -finishes execution. Therefore the coroutine library itself needs to +finishes execution. Therefore, the coroutine library itself needs to maintain a stack of generators. The ``connection.sendall()`` call waits until the socket is writable and does a similar thing to what ``socket.sendall()`` does. diff --git a/pep-0423.txt b/pep-0423.txt index 432620cc65a..50573993f71 100644 --- a/pep-0423.txt +++ b/pep-0423.txt @@ -379,7 +379,7 @@ As an example, we can find Plone portlets in many places: name. Even if Plone community has conventions, using the name to categorize -distributions is inapropriate. It's impossible to get the full list of +distributions is inappropriate. It's impossible to get the full list of distributions that provide portlets for Plone by filtering on names. But it would be possible if all these distributions used "Framework :: Plone" classifier and "portlet" keyword. @@ -689,7 +689,7 @@ characteristics: * ``Development Status :: 7 - Inactive`` classifier. * latest version is empty, except packaging stuff. -* lastest version "redirects" to another distribution. E.g. it has a +* latest version "redirects" to another distribution. E.g. it has a single dependency on the renamed project. * referenced as ``Obsoletes-Dist`` in a newer distribution. @@ -737,7 +737,7 @@ Apply these guidelines on your projects, then the community will see it is safe. In particular, "leaders" such as authors of popular projects are -influential, they have power and, thus, responsability over +influential, they have power and, thus, responsibility over communities. Apply these guidelines on popular projects, then communities will diff --git a/pep-0425.txt b/pep-0425.txt index 9f863c84c7a..2143094d2fd 100644 --- a/pep-0425.txt +++ b/pep-0425.txt @@ -263,7 +263,7 @@ Why is the ABI tag (the second tag) sometimes "none" in the reference implementa Since Python 2 does not have an easy way to get to the SOABI (the concept comes from newer versions of Python 3) the reference implentation at the time of writing guesses "none". Ideally it - would detect "py27(d|m|u)" analagous to newer versions of Python, + would detect "py27(d|m|u)" analogous to newer versions of Python, but in the meantime "none" is a good enough way to say "don't know". diff --git a/pep-0426.txt b/pep-0426.txt index 1c8bcabe9d9..55cf96507af 100644 --- a/pep-0426.txt +++ b/pep-0426.txt @@ -219,7 +219,7 @@ may also have importable submodules. a release, prior to creation of an sdist or binary archive. An "sdist" is a publication format providing the distribution metadata and -and any source files that are essential to creating a binary archive for +any source files that are essential to creating a binary archive for the distribution. Creating a binary archive from an sdist requires that the appropriate build tools be available on the system. @@ -772,7 +772,7 @@ for specific activities, making it easier to minimise installation footprints in constrained environments (regardless of the reasons for those constraints). -Distributions may declare five differents kinds of dependency: +Distributions may declare five different kinds of dependency: * Runtime dependencies: other distributions that are needed to actually use this distribution (but are not considered subdistributions). diff --git a/pep-0428.txt b/pep-0428.txt index dd498df9e79..589897858d7 100644 --- a/pep-0428.txt +++ b/pep-0428.txt @@ -690,7 +690,7 @@ joinpath() The joinpath() method was initially called join(), but several people objected that it could be confused with str.join() which has different -semantics. Therefore it was renamed to joinpath(). +semantics. Therefore, it was renamed to joinpath(). Case-sensitivity ---------------- diff --git a/pep-0431.txt b/pep-0431.txt index 92f6c1362c3..9f7be418f1e 100644 --- a/pep-0431.txt +++ b/pep-0431.txt @@ -24,7 +24,7 @@ Withdrawal After lengthy discussion it has turned out that the things I thought was problem in datetime's implementation are intentional. Those include -completely ignoring DST transistions when making date time arithmetic. +completely ignoring DST transitions when making date time arithmetic. That makes the is_dst flags part of this PEP pointless, as they would have no useful function. ``datetime`` by design does not separate between ambiguous datetimes and will never do so. @@ -49,7 +49,7 @@ few months later. Time zone support has therefore only been available through two third-party modules, ``pytz`` and ``dateutil``, both who include and wrap the "zoneinfo" database. This database, also called "tz" or "The Olsen database", is the -de-facto standard time zone database over time zones, and it is included in +de facto standard time zone database over time zones, and it is included in most Unix and Unix-like operating systems, including OS X. This gives us the opportunity to include the code that supports the zoneinfo @@ -86,7 +86,7 @@ are ambiguous and therefore you can't rely on them to figure out which time zone you are located in. There is however a standard for finding the compiled time zone information -since it's located in ``/etc/localtime``. Therefore it is possible to create +since it's located in ``/etc/localtime``. Therefore, it is possible to create a local time zone object with the correct time zone information even though you don't know the name of the time zone. A function in ``datetime`` should be provided to return the local time zone. diff --git a/pep-0432.txt b/pep-0432.txt index b8fad4667ae..1389edc4887 100644 --- a/pep-0432.txt +++ b/pep-0432.txt @@ -93,7 +93,7 @@ tracing when launching Python subprocesses [9_]). Rather than continuing to bolt such behaviour onto an already complicated system, this PEP proposes to start simplifying the status quo by introducing -a more stuctured startup sequence, with the aim of making these further +a more structured startup sequence, with the aim of making these further feature requests easier to implement. @@ -186,7 +186,7 @@ be able to control the following aspects of the final interpreter state: * ``sys.path`` -* The command line arguments seen by the interpeter: +* The command line arguments seen by the interpreter: * ``sys.argv`` @@ -443,7 +443,7 @@ between the App bundle and the main Python binary). ``use_hash_seed`` controls the configuration of the randomised hash algorithm. If it is zero, then randomised hashes with a random seed will -be used. It it is positive, then the value in ``hash_seed`` will be used +be used. It is positive, then the value in ``hash_seed`` will be used to seed the random number generator. If the ``hash_seed`` is zero in this case, then the randomised hashing is disabled completely. @@ -962,7 +962,7 @@ configuration settings stored in global variables and environment variables, and that ``Py_InitializeMainInterpreter()`` writes affected settings back to the relevant locations. -One acknowledged incompatiblity is that some environment variables which +One acknowledged incompatibility is that some environment variables which are currently read lazily may instead be read once during interpreter initialization. As the PEP matures, these will be discussed in more detail on a case by case basis. The environment variables which are currently diff --git a/pep-0433.txt b/pep-0433.txt index c358cd391c6..6582d0dfbee 100644 --- a/pep-0433.txt +++ b/pep-0433.txt @@ -104,7 +104,7 @@ untrusted child process can read sensitive data like passwords and take control of the parent process though leaked file descriptors. It is for example a known vulnerability to escape from a chroot. -See also the CERT recommandation: +See also the CERT recommendation: `FIO42-C. Ensure files are properly closed when they are no longer needed `_. @@ -124,7 +124,7 @@ Example of vulnerabilities: `_ (fixed in 2009) * PHP: `system() (and similar) don't cleanup opened handles of Apache - `_ (not fixed in january + `_ (not fixed in January 2013) @@ -308,7 +308,7 @@ Drawbacks of setting close-on-exec flag by default: Backward compatibility: only a few programs rely on inheritance of file descriptors, and they only pass a few file descriptors, usually just -one. These programs will fail immediatly with ``EBADF`` error, and it +one. These programs will fail immediately with ``EBADF`` error, and it will be simple to fix them: add ``cloexec=False`` parameter or use ``os.set_cloexec(fd, False)``. diff --git a/pep-0436.txt b/pep-0436.txt index 738ceb32131..b2af92d0442 100644 --- a/pep-0436.txt +++ b/pep-0436.txt @@ -376,7 +376,7 @@ unit. For example, to specify a parameter "foo" as taking a Python Although these resemble ``PyArg_ParseTuple`` format units, no guarantee is made that the implementation will call a ``PyArg_Parse`` function for parsing. -This syntax does not support parameters. Therefore it doesn't support any +This syntax does not support parameters. Therefore, it doesn't support any of the format units that require input parameters (``"O!", "O&", "es", "es#", "et", "et#"``). Parameters requiring one of these conversions cannot use the legacy syntax. (You may still, however, supply a default value.) diff --git a/pep-0440.txt b/pep-0440.txt index 45c96bf051f..8e89c38c623 100644 --- a/pep-0440.txt +++ b/pep-0440.txt @@ -438,7 +438,7 @@ Pre-release separators Pre-releases should allow a ``.``, ``-``, or ``_`` separator between the release segment and the pre-release segment. The normal form for this is without a separator. This allows versions such as ``1.1.a1`` or ``1.1-a1`` -which would be normalized to ``1.1a1``. It should also allow a seperator to +which would be normalized to ``1.1a1``. It should also allow a separator to be used between the pre-release signifier and the numeral. This allows versions such as ``1.0a.1`` which would be normalized to ``1.0a1``. @@ -468,7 +468,7 @@ Post release separators Post releases allow a ``.``, ``-``, or ``_`` separator as well as omitting the separator all together. The normal form of this is with the ``.`` separator. This allows versions such as ``1.2-post2`` or ``1.2post2`` which normalize to -``1.2.post2``. Like the pre-release seperator this also allows an optional +``1.2.post2``. Like the pre-release separator this also allows an optional separator between the post release signifier and the numeral. This allows versions like ``1.2.post-2`` which would normalize to ``1.2.post2``. @@ -485,7 +485,7 @@ normal forms. Implicit post release number ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Post releases allow omiting the numeral in which case it is implicitly assumed +Post releases allow omitting the numeral in which case it is implicitly assumed to be ``0``. The normal form for this is to include the ``0`` explicitly. This allows versions such as ``1.2.post`` which is normalized to ``1.2.post0``. @@ -497,7 +497,7 @@ Post releases allow omitting the ``post`` signifier all together. When using this form the separator MUST be ``-`` and no other form is allowed. This allows versions such as ``1.0-1`` to be normalized to ``1.0.post1``. This particular normalization MUST NOT be used in conjunction with the implicit post release -number rule. In other words ``1.0-`` is *not* a valid version and it does *not* +number rule. In other words, ``1.0-`` is *not* a valid version and it does *not* normalize to ``1.0.post0``. @@ -513,7 +513,7 @@ normalize to ``1.2.dev2``. Implicit development release number ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Development releases allow omiting the numeral in which case it is implicitly +Development releases allow omitting the numeral in which case it is implicitly assumed to be ``0``. The normal form for this is to include the ``0`` explicitly. This allows versions such as ``1.2.dev`` which is normalized to ``1.2.dev0``. @@ -1170,14 +1170,14 @@ the third slash MUST still exist. The ```` defines what the file path on the filesystem that is to be accessed. On the various \*nix operating systems the only allowed values for ```` -is for it to be ommitted, ``localhost``, or another FQDN that the current -machine believes matches its own host. In other words on \*nix the ``file://`` +is for it to be omitted, ``localhost``, or another FQDN that the current +machine believes matches its own host. In other words, on \*nix the ``file://`` scheme can only be used to access paths on the local machine. On Windows the file format should include the drive letter if applicable as part of the ```` (e.g. ``file:///c:/path/to/a/file``). Unlike \*nix on Windows the ```` parameter may be used to specify a file residing on a -network share. In other words in order to translate ``\\machine\volume\file`` +network share. In other words, in order to translate ``\\machine\volume\file`` to a ``file://`` url, it would end up as ``file://machine/volume/file``. For more information on ``file://`` URLs on Windows see MSDN [4]_. @@ -1476,7 +1476,7 @@ a few simple rules but otherwise it more or less relies largely on string comparison. The normalization rules provided in this PEP exist primarily to either increase -the compatability with ``pkg_resources.parse_version``, particularly in +the compatibility with ``pkg_resources.parse_version``, particularly in documented use cases such as ``rev``, ``r``, ``pre``, etc or to do something more reasonable with versions that already exist on PyPI. diff --git a/pep-0444.txt b/pep-0444.txt index 435ffb759fe..374cc162cc1 100644 --- a/pep-0444.txt +++ b/pep-0444.txt @@ -839,7 +839,7 @@ across Python versions, developers must do these things: .. XXX -#) Dont try to use the ``format`` method or the ``__mod__`` method of +#) Don't try to use the ``format`` method or the ``__mod__`` method of instances of bytes (directly or indirectly). In Python 2, the ``str`` type which we treat equivalently to Python 3's ``bytes`` supports these method but actual Python 3's ``bytes`` instances diff --git a/pep-0445.txt b/pep-0445.txt index 3ef9659cf36..7ad1093d4e6 100644 --- a/pep-0445.txt +++ b/pep-0445.txt @@ -7,7 +7,7 @@ BDFL-Delegate: Antoine Pitrou Status: Final Type: Standards Track Content-Type: text/x-rst -Created: 15-june-2013 +Created: 15-Jun-2013 Python-Version: 3.4 Resolution: http://mail.python.org/pipermail/python-dev/2013-July/127222.html @@ -284,7 +284,7 @@ Use case 2: Replace Memory Allocators, override pymalloc -------------------------------------------------------- If you have a dedicated allocator optimized for allocations of objects -smaller than 512 bytes with a short lifetime, pymalloc can be overriden +smaller than 512 bytes with a short lifetime, pymalloc can be overridden (replace ``PyObject_Malloc()``). Dummy example wasting 2 bytes per memory block:: @@ -702,7 +702,7 @@ and it is contiguous. On Windows, the heap is handled by ``mmap()`` on UNIX and ``VirtualAlloc()`` on Windows, they can be discontiguous. -Releasing a memory mapping gives back immediatly the memory to the +Releasing a memory mapping gives back immediately the memory to the system. On UNIX, the heap memory is only given back to the system if the released block is located at the end of the heap. Otherwise, the memory will only be given back to the system when all the memory located after diff --git a/pep-0446.txt b/pep-0446.txt index e352a0cd6fb..ee6c2d3e5d7 100644 --- a/pep-0446.txt +++ b/pep-0446.txt @@ -100,7 +100,7 @@ Only Inherit Some Handles on Windows ------------------------------------ Since Windows Vista, ``CreateProcess()`` supports an extension of the -STARTUPINFO struture: the `STARTUPINFOEX structure +STARTUPINFO structure: the `STARTUPINFOEX structure `_. Using this new structure, it is possible to specify a list of handles to inherit: ``PROC_THREAD_ATTRIBUTE_HANDLE_LIST``. Read `Programmatically diff --git a/pep-0447.txt b/pep-0447.txt index be9baa03a26..b63c3ba76a4 100644 --- a/pep-0447.txt +++ b/pep-0447.txt @@ -86,7 +86,7 @@ added in a central location. .. note:: `PyObjC`_ cannot precalculate the contents of the class ``__dict__`` - because Objective-C classes can grow new methods at runtime. Furthermore + because Objective-C classes can grow new methods at runtime. Furthermore, Objective-C classes tend to contain a lot of methods while most Python code will only use a small subset of them, this makes precalculating unnecessarily expensive. @@ -109,11 +109,11 @@ unchanged unless a metatype actually defines the new special method. Aside: Attribute resolution algorithm in Python ----------------------------------------------- -The attribute resolution proces as implemented by ``object.__getattribute__`` +The attribute resolution process as implemented by ``object.__getattribute__`` (or PyObject_GenericGetAttr`` in CPython's implementation) is fairly straightforward, but not entirely so without reading C code. -The current CPython implementation of object.__getattribute__ is basicly +The current CPython implementation of object.__getattribute__ is basically equivalent to the following (pseudo-) Python code (excluding some house keeping and speed tricks):: @@ -635,7 +635,7 @@ Alternative placement of the new method This PEP proposes to add ``__getdescriptor__`` as a method on the metaclass. An alternative would be to add it as a class method on the class itself -(simular to how ``__new__`` is a `staticmethod`_ of the class and not a method +(similar to how ``__new__`` is a `staticmethod`_ of the class and not a method of the metaclass). The advantage of using a method on the metaclass is that will give an error diff --git a/pep-0449.txt b/pep-0449.txt index d479d3bc335..bd4e1f1f3ca 100644 --- a/pep-0449.txt +++ b/pep-0449.txt @@ -49,7 +49,7 @@ naming scheme: * The auto discovery protocol and use of the consistent naming scheme has only ever been implemented by one installer (pip), and its implementation, besides being insecure, has serious issues with performance and is slated for removal - with it's next release (1.5). + with its next release (1.5). * While there are provisions in `PEP381`_ that would solve *some* of these issues for a dedicated client it would not solve the issues that affect a users browser. Additionally these provisions have not been implemented by @@ -110,7 +110,7 @@ configurations to point away from those domains this has a number of issues. the redirect to HTTPS prior to giving it to the client. * The overhead of maintaining several domains pointing at PyPI has proved troublesome for the small number of N.pypi.python.org domains that have - already been reclaimed. They often times get mis-configured when things + already been reclaimed. They oftentimes get mis-configured when things change on the service which often leaves them broken for months at a time until somebody notices. By leaving them in we leave users of these domains open to random breakages which are less likely to get caught or noticed. diff --git a/pep-0450.txt b/pep-0450.txt index 3ff09e09030..6e33e2c9b8b 100644 --- a/pep-0450.txt +++ b/pep-0450.txt @@ -135,7 +135,7 @@ Rationale others to do so[10]. It isn't just the variance and standard deviation. Even the mean is not - quite as straight-forward as it might appear. The above implementation + quite as straightforward as it might appear. The above implementation seems too simple to have problems, but it does: - The built-in sum can lose accuracy when dealing with floats of wildly diff --git a/pep-0451.txt b/pep-0451.txt index d0c5b65ee46..b78a3d61618 100644 --- a/pep-0451.txt +++ b/pep-0451.txt @@ -165,7 +165,7 @@ loaders and sys.meta_path. The importlib module, introduced with Python 3.1, now exposes a pure Python implementation of the APIs described by PEP 302, as well as of the full import system. It is now much easier to understand and extend the import system. While a benefit -to the Python community, this greater accessabilty also presents a +to the Python community, this greater accessibility also presents a challenge. As more developers come to understand and customize the import system, @@ -404,7 +404,7 @@ finders and loaders should change relative to this PEP: The ModuleSpec factory functions in importlib.util are intended to be helpful for converting existing finders. spec_from_loader() and -spec_from_file_location() are both straight-forward utilities in this +spec_from_file_location() are both straightforward utilities in this regard. For existing loaders, exec_module() should be a relatively direct @@ -896,7 +896,7 @@ the specific uses of module specs by the import machinery: * load() - an analogue to the deprecated Loader.load_module(). As with the factory functions, exposing these methods via -module.__spec__ is less than desireable. They would end up being an +module.__spec__ is less than desirable. They would end up being an attractive nuisance, even if only exposed as "private" attributes (as they were in previous versions of this PEP). If someone finds a need for these methods later, we can expose the via an appropriate API diff --git a/pep-0452.txt b/pep-0452.txt index b7cc649e123..61d91954fea 100644 --- a/pep-0452.txt +++ b/pep-0452.txt @@ -77,7 +77,7 @@ Specification hashing object, measured in bytes. If the hash has a variable output size, this output size must be chosen when the hashing object is created, and this attribute must contain the - selected size. Therefore None is *not* a legal value for this + selected size. Therefore, None is *not* a legal value for this attribute. block_size @@ -179,7 +179,7 @@ Changes from Version 1.0 to Version 2.0 Version 2.0 of API for Cryptographic Hash Functions clarifies some aspects of the API and brings it up-to-date. It also formalized aspects - that were already de-facto standards and provided by most + that were already de facto standards and provided by most implementations. Version 2.0 introduces the following new attributes: diff --git a/pep-0455.txt b/pep-0455.txt index ebdb2bf7205..9bb6d94d9a4 100644 --- a/pep-0455.txt +++ b/pep-0455.txt @@ -180,7 +180,7 @@ the generic construct, and it can fill more use cases. Even case-insensitive dicts can actually elicit different transformation functions: ``str.lower``, ``str.casefold`` or in some cases ``bytes.lower`` -when working with text encoded in a ASCII-compatible encoding. +when working with text encoded in an ASCII-compatible encoding. Other constructor patterns -------------------------- diff --git a/pep-0456.txt b/pep-0456.txt index 8ef12ed9c61..2fc46bdebd5 100644 --- a/pep-0456.txt +++ b/pep-0456.txt @@ -34,7 +34,7 @@ seen yet, the weakness has to be fixed. Jean-Philippe Aumasson and Daniel J. Bernstein have already shown how the seed for the current implementation can be recovered [poc]_. -Furthermore the current hash algorithm is hard-coded and implemented multiple +Furthermore, the current hash algorithm is hard-coded and implemented multiple times for bytes and three different Unicode representations UCS1, UCS2 and UCS4. This makes it impossible for embedders to replace it with a different implementation without patching and recompiling large parts of the interpreter. @@ -208,7 +208,7 @@ The 128-bit variants requires a 64-bit data type and are not compatible with pure C89 platforms. The 32-bit variant is fully C89-compatible. Aumasson, Bernstein and Boßlet have shown [sip]_ [ocert-2012-001]_ that -Murmur3 is not resilient against hash collision attacks. Therefore Murmur3 +Murmur3 is not resilient against hash collision attacks. Therefore, Murmur3 can no longer be considered as secure algorithm. It still may be an alternative is hash collision attacks are of no concern. @@ -266,9 +266,9 @@ Small string optimization Hash functions like SipHash24 have a costly initialization and finalization code that can dominate speed of the algorithm for very short strings. On the -other hand Python calculates the hash value of short strings quite often. A +other hand, Python calculates the hash value of short strings quite often. A simple and fast function for especially for hashing of small strings can make -a measurable impact on performance. For example these measurements were taken +a measurable impact on performance. For example, these measurements were taken during a run of Python's regression tests. Additional measurements of other code have shown a similar distribution. @@ -321,7 +321,7 @@ hash secret The ``_Py_HashSecret_t`` type of Python 2.6 to 3.3 has two members with either 32- or 64-bit length each. SipHash requires two 64-bit unsigned integers as -keys. The typedef will be changed to an union with a guaranteed size of 24 +keys. The typedef will be changed to a union with a guaranteed size of 24 bytes on all architectures. The union provides a 128 bit random key for SipHash24 and FNV as well as an additional value of 64 bit for the optional small string optimization and pyexpat seed. The additional 64 bit seed ensures @@ -553,7 +553,7 @@ Serhiy Storchaka has shown in [issue16427]_ that a modified FNV implementation with 64 bits per cycle is able to process long strings several times faster than the current FNV implementation. -However according to statistics [issue19183]_ a typical Python program as +However, according to statistics [issue19183]_ a typical Python program as well as the Python test suite have a hash ratio of about 50% small strings between 1 and 6 bytes. Only 5% of the strings are larger than 16 bytes. @@ -617,7 +617,7 @@ versions of the PEP aim for compile time configuration. Non-aligned memory access ------------------------- -The implementation of SipHash24 were critized because it ignores the issue +The implementation of SipHash24 were criticized because it ignores the issue of non-aligned memory and therefore doesn't work on architectures that requires alignment of integer types. The PEP deliberately neglects this special case and doesn't support SipHash24 on such platforms. It's simply diff --git a/pep-0458.txt b/pep-0458.txt index 487d413cf14..08ae6146cc8 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -519,7 +519,7 @@ Project developers expect the distributions they upload to PyPI to be immediately available for download. Unfortunately, there will be problems when many readers and writers simultaneously access the same metadata and distributions. That is, there needs to be a way to ensure consistency of -metadata and repository files when multiple developers simulaneously change the +metadata and repository files when multiple developers simultaneously change the same metadata or distributions. There are also issues with consistency on PyPI without TUF, but the problem is more severe with signed metadata that MUST keep track of the files available on PyPI in real-time. diff --git a/pep-0460.txt b/pep-0460.txt index a6c7754e058..c2fc0adb0a8 100644 --- a/pep-0460.txt +++ b/pep-0460.txt @@ -94,7 +94,7 @@ through the percent operator or the ``str.format()`` method) are unsupported. Those features imply treating the recipient of the operator or method as text, which goes counter to the text / bytes separation (for example, accepting ``%d`` as a format code would imply -that the bytes object really is a ASCII-compatible text string). +that the bytes object really is an ASCII-compatible text string). Amongst those unsupported features are not only most type-specific format codes, but also the various layout specifiers such as padding diff --git a/pep-0463.txt b/pep-0463.txt index c9c989f208a..ca754c648c5 100644 --- a/pep-0463.txt +++ b/pep-0463.txt @@ -755,7 +755,7 @@ finally clause -------------- The statement form try... finally or try... except... finally has no -logical corresponding expression form. Therefore the finally keyword +logical corresponding expression form. Therefore, the finally keyword is not a part of this proposal, in any way. diff --git a/pep-0465.txt b/pep-0465.txt index 5db46368a52..ebed4df3b44 100644 --- a/pep-0465.txt +++ b/pep-0465.txt @@ -451,7 +451,7 @@ appear in many important applications, and that numerical libraries like numpy are used by a substantial proportion of Python's user base. But numerical libraries aren't just about matrix formulas, and being important doesn't necessarily mean taking up a lot of code: if matrix -formulas only occured in one or two places in the average +formulas only occurred in one or two places in the average numerically-oriented project, then it still wouldn't be worth adding a new operator. So how common is matrix multiplication, really? @@ -1107,7 +1107,7 @@ by other means, and that causes painful reverberations through the larger ecosystem. Defining a new language (presumably with its own parser which would have to be kept in sync with Python's, etc.), just to support a single binary operator, is neither practical nor -desireable. In the numerical context, Python's competition is +desirable. In the numerical context, Python's competition is special-purpose numerical languages (Matlab, R, IDL, etc.). Compared to these, Python's killer feature is exactly that one can mix specialized numerical code with code for XML parsing, web page diff --git a/pep-0468.txt b/pep-0468.txt index 488e97790fb..b51c8c9c0a6 100644 --- a/pep-0468.txt +++ b/pep-0468.txt @@ -43,7 +43,7 @@ which is then passed as a single argument to the function. With the capability described in this PEP, that boilerplate would no longer be required. -For comparision, currently:: +For comparison, currently:: kwargs = OrderedDict() kwargs['eggs'] = ... diff --git a/pep-0470.txt b/pep-0470.txt index b2ff9cee80d..2ab5d62ba7d 100644 --- a/pep-0470.txt +++ b/pep-0470.txt @@ -52,7 +52,7 @@ This confusion comes down to end users of projects not realizing if a project is hosted on PyPI or if it relies on an external service. This often manifests itself when the external service is down but PyPI is not. People will see that PyPI works, and other projects works, but this one specific one does not. They -often times do not realize who they need to contact in order to get this fixed +oftentimes do not realize who they need to contact in order to get this fixed or what their remediation steps are. PEP 438 attempted to solve this issue by allowing projects to explicitly @@ -321,7 +321,7 @@ execute arbitrary Python code on the end users machine) and a reliability concern and that PEP 438 attempted to resolve this by making them explicitly opt in, but that PEP 438 brought along with it a number of serious usability issues. PEP 470 represents a simplification of the model to a model that many -users will be familar with, which is common amongst Linux distributions. +users will be familiar with, which is common amongst Linux distributions. Switching to a repository structure breaks my workflow or isn't allowed by my host? @@ -366,7 +366,7 @@ concerned with and that you'd be replacing if you're running your own repository. However, it also provides a central registry of who owns what name in order to prevent naming collisions, think of it sort of as DNS but for Python packages. In addition to making sure that names are handed out in a -first come, first serve manner it also provides a single place for users to go +first-come, first-served manner it also provides a single place for users to go to look search for and discover new projects. So the simple answer is, you should still register your project with PyPI to avoid naming collisions and to make it so people can still easily discover your project. @@ -430,7 +430,7 @@ These proposals are rejected because: * The mechanism paints a very broad brush when enabling an option, while PEP 438 attempts to limit this with per package options. However a project - that has existed for an extended period of time may often times have several + that has existed for an extended period of time may oftentimes have several different URLs listed in their simple index. It is not unusual for at least one of these to no longer be under control of the project. While an unregistered domain will sit there relatively harmless most of the time, pip diff --git a/pep-0471.txt b/pep-0471.txt index e3f8a1e0388..c058310aab8 100644 --- a/pep-0471.txt +++ b/pep-0471.txt @@ -469,7 +469,7 @@ follow symlinks, but there was basic consensus among the most involved participants, and this PEP's author believes that the above case is strong enough to warrant following symlinks by default. -In addition, it's straight-forward to call the relevant methods with +In addition, it's straightforward to call the relevant methods with ``follow_symlinks=False`` if the other behaviour is desired. diff --git a/pep-0474.txt b/pep-0474.txt index 0e1cdf33331..ade903a2018 100644 --- a/pep-0474.txt +++ b/pep-0474.txt @@ -279,7 +279,7 @@ the `Fedora Infrastructure Apprentice `GNOME Infrastructure Apprentice `__ programs. -Instead, systems tend to be maintained largely by developers as a part time +Instead, systems tend to be maintained largely by developers as a part-time activity on top of their development related contributions, rather than seeking to recruit folks that are more interested in operations (i.e. keeping existing systems running well) than they are in development (i.e. @@ -419,7 +419,7 @@ with the rollout of the following pilot deployment: services) * automatic linking of issue references in code review comments and commit messages to the corresponding issues on bugs.python.org -* draft updates to PEP 1 explaining the Kallithea based PEP editing and +* draft updates to PEP 1 explaining the Kallithea-based PEP editing and submission workflow The following items would be needed for a production migration, but there diff --git a/pep-0475.txt b/pep-0475.txt index ea025bc697f..57e90126b16 100644 --- a/pep-0475.txt +++ b/pep-0475.txt @@ -263,7 +263,7 @@ A possible strategy is to set up a signal handler raising a well-defined exception, or use a wakeup file descriptor. For applications using event loops, ``signal.set_wakeup_fd()`` is the -recommanded option to handle signals. Python's low-level signal handler +recommended option to handle signals. Python's low-level signal handler will write signal numbers into the file descriptor and the event loop will be awaken to read them. The event loop can handle those signals without the restriction of signal handlers (for example, the loop can diff --git a/pep-0477.txt b/pep-0477.txt index c9e23d7fc53..bb7520df241 100644 --- a/pep-0477.txt +++ b/pep-0477.txt @@ -56,7 +56,7 @@ reasons: install the package manager. 4. One of Pythons biggest strengths is in the huge ecosystem of libraries and projects that have been built on top of it, most of which are distributed - through PyPI. However in order to benefit from this wide ecosystem + through PyPI. However, in order to benefit from this wide ecosystem meaningfully requires end users, some of which are going to be new, to make a decision on which package manager they should get, how to get it, and then finally actually installing it first. @@ -101,7 +101,7 @@ Disabling ensurepip by Downstream Distributors ============================================== Due to its use in the ``venv`` module, downstream distributors cannot disable -the ``ensurepip`` module in Python 3.4. However since Python 2.7 has no such +the ``ensurepip`` module in Python 3.4. However, since Python 2.7 has no such module it is explicitly allowed for downstream distributors to patch the ``ensurepip`` module to prevent it from installing anything. diff --git a/pep-0481.txt b/pep-0481.txt index 5032e48c916..6e559411413 100644 --- a/pep-0481.txt +++ b/pep-0481.txt @@ -68,7 +68,7 @@ capabilities of the VCS itself as well as the network effect and mindshare of the community around that VCS. There are really only two real options for this, Mercurial and Git. Between the -two of them the technical capabilities are largely equivilant. For this reason +two of them the technical capabilities are largely equivalent. For this reason this PEP will largely ignore the technical arguments about the VCS system and will instead focus on the social aspects. @@ -223,7 +223,7 @@ ourselves to a more standard workflow. This standardization pays off in the ability to re-use tools out of the box freeing up developer time to actually work on Python itself as well as enabling knowledge sharing between projects. -However if we do need to modify the tooling, Git itself is largely written in +However, if we do need to modify the tooling, Git itself is largely written in C the same as CPython itself is. It can also have commands written for it using any language, including Python. Phabricator is written in PHP which is a fairly common language in the web world and fairly easy to pick up. GitHub itself is @@ -266,8 +266,8 @@ can stop being benevolent. This is hedged against in a few ways: already be in place if we ever need to stop using GitHub. Relying on GitHub comes with a number of benefits beyond just the benefits of -the platform itself. Since it is a commercially backed venture it has a full -time staff responsible for maintaining its services. This includes making sure +the platform itself. Since it is a commercially backed venture it has a full-time +staff responsible for maintaining its services. This includes making sure they stay up, making sure they stay patched for various security vulnerabilities, and further improving the software and infrastructure as time goes on. @@ -321,7 +321,7 @@ of a DVCS, the repository hosting, and the workflow used is the social network and size of the community using said tools. We can see this is true by looking at an example from a sub-community of the Python community: The Scientific Python community. They have already migrated most of the key pieces of the -SciPy stack onto Github using the Pull Request based workflow. This process +SciPy stack onto Github using the Pull Request-based workflow. This process started with IPython, and as more projects moved over it became a natural default for new projects in the community. diff --git a/pep-0483.txt b/pep-0483.txt index 332c6c4d464..88a135ffab4 100644 --- a/pep-0483.txt +++ b/pep-0483.txt @@ -238,7 +238,7 @@ Types vs. Classes ----------------- In Python, classes are object factories defined by the ``class`` statement, -and and returned by the ``type(obj)`` built-in function. Class is a dynamic, +and returned by the ``type(obj)`` built-in function. Class is a dynamic, runtime concept. Type concept is described above, types appear in variable diff --git a/pep-0484.txt b/pep-0484.txt index 9c7bdefd847..1858e4cc425 100644 --- a/pep-0484.txt +++ b/pep-0484.txt @@ -586,7 +586,7 @@ Type variables with an upper bound ---------------------------------- A type variable may specify an upper bound using ``bound=``. -This means that an actual type substituted (explicitly or implictly) +This means that an actual type substituted (explicitly or implicitly) for the type variable must be a subtype of the boundary type. A common example is the definition of a Comparable type that works well enough to catch the most common errors:: @@ -865,7 +865,7 @@ for a variable. Example:: return x * 2 To allow precise typing in such situations, the user should use -the ``Union`` type in conjuction with the ``enum.Enum`` class provided +the ``Union`` type in conjunction with the ``enum.Enum`` class provided by the standard library, so that type errors can be caught statically:: from typing import Union diff --git a/pep-0485.txt b/pep-0485.txt index cccc5657ac5..77e5f10025f 100644 --- a/pep-0485.txt +++ b/pep-0485.txt @@ -113,7 +113,7 @@ Non-float types The primary use-case is expected to be floating point numbers. However, users may want to compare other numeric types similarly. In theory, it should work for any type that supports ``abs()``, -multiplication, comparisons, and subtraction. However, the implimentation +multiplication, comparisons, and subtraction. However, the implementation in the math module is written in C, and thus can not (easily) use python's duck typing. Rather, the values passed into the funciton will be converted to the float type before the calculation is performed. Passing in types @@ -401,7 +401,7 @@ Large Tolerances ---------------- The most common use case is expected to be small tolerances -- on order of the -default 1e-9. However there may be use cases where a user wants to know if two +default 1e-9. However, there may be use cases where a user wants to know if two fairly disparate values are within a particular range of each other: "is a within 200% (rel_tol = 2.0) of b? In this case, the strong test would never indicate that two values are within that range of each other if one of them is diff --git a/pep-0487.txt b/pep-0487.txt index 13d7237fda5..dfb949f0343 100644 --- a/pep-0487.txt +++ b/pep-0487.txt @@ -55,7 +55,7 @@ Proposal While there are many possible ways to use a metaclass, the vast majority of use cases falls into just three categories: some initialization code -running after class creation, the initalization of descriptors and +running after class creation, the initialization of descriptors and keeping the order in which class attributes were defined. Those three use cases can easily be performed by just one metaclass. If @@ -217,7 +217,7 @@ While the metaclass is still in the standard library and not in the language, it may still clash with other metaclasses. The most prominent metaclass in use is probably ABCMeta. It is also a particularly good example for the need of combining metaclasses. For -users who want to define a ABC with subclass initialization, we should +users who want to define an ABC with subclass initialization, we should support a ``ABCSubclassInit`` class, or let ABCMeta inherit from this PEP's metaclass. diff --git a/pep-0494.txt b/pep-0494.txt index f2dfab49731..fa079b84e48 100644 --- a/pep-0494.txt +++ b/pep-0494.txt @@ -73,7 +73,7 @@ Proposed changes for 3.6: * PEP 447, Add __getdescriptor__ method to metaclass * PEP 495, Local Time Disambiguation * PEP 498, Literal String Formatting -* PEP 499, python -m foo should bind sys.modules['foo'] in additon +* PEP 499, python -m foo should bind sys.modules['foo'] in addition to sys.modules['__main__'] diff --git a/pep-0498.txt b/pep-0498.txt index 32a446c2c19..4aeb51fffc3 100644 --- a/pep-0498.txt +++ b/pep-0498.txt @@ -594,7 +594,7 @@ each value. Raw f-strings ------------- -Raw and f-strings may be combined. For example they could be used to +Raw and f-strings may be combined. For example, they could be used to build up regular expressions:: >>> header = 'Subject' diff --git a/pep-0499.txt b/pep-0499.txt index fe304e3b791..56307fa9730 100644 --- a/pep-0499.txt +++ b/pep-0499.txt @@ -1,5 +1,5 @@ PEP: 499 -Title: ``python -m foo`` should bind ``sys.modules['foo']`` in additon to ``sys.modules['__main__']`` +Title: ``python -m foo`` should bind ``sys.modules['foo']`` in addition to ``sys.modules['__main__']`` Version: $Revision$ Last-Modified: $Date$ Author: Cameron Simpson diff --git a/pep-0500.txt b/pep-0500.txt index a1c64eb4026..bda3379edf3 100644 --- a/pep-0500.txt +++ b/pep-0500.txt @@ -39,7 +39,7 @@ local clocks were rolled back one hour at 2014-11-02T02:00, introducing an extra hour in the night between 2014-11-01 and 2014-11-02. -Many business applications requre the use of Python's simplified view +Many business applications require the use of Python's simplified view of local dates. No self-respecting car rental company will charge its customers more for a week that straddles the end of DST than for any other week or require that they return the car an hour early. diff --git a/pep-0501.txt b/pep-0501.txt index d702a4884bf..e623c28ed51 100644 --- a/pep-0501.txt +++ b/pep-0501.txt @@ -258,7 +258,7 @@ NOTE: Exposing them more directly to custom renderers would increase the complexity of the ``InterpolationTemplate`` definition without providing an increase in expressiveness (since they're redundant with calling the builtins - directly). At the same time, they *are* made available as arbitary strings + directly). At the same time, they *are* made available as arbitrary strings when writing custom ``string.Formatter`` implementations, so it may be desirable to offer similar levels of flexibility of interpretation in interpolation templates. @@ -465,7 +465,7 @@ Deferring support for binary interpolation Supporting binary interpolation with this syntax would be relatively straightforward (the elements in the parsed fields tuple would just be byte strings rather than text strings, and the default renderer would be -markedly less useful), but poses a signficant likelihood of producing +markedly less useful), but poses a significant likelihood of producing confusing type errors when a text renderer was presented with binary input. @@ -517,7 +517,7 @@ Deferring consideration of possible use in i18n use cases The initial motivating use case for this PEP was providing a cleaner syntax for i18n translation, as that requires access to the original unmodified -template. As such, it focused on compatibility with the subsitution syntax used +template. As such, it focused on compatibility with the substitution syntax used in Python's ``string.Template`` formatting and Mozilla's l20n project. However, subsequent discussion revealed there are significant additional diff --git a/pep-0502.txt b/pep-0502.txt index dbb1db34c2d..c30a5fe9f04 100644 --- a/pep-0502.txt +++ b/pep-0502.txt @@ -104,7 +104,7 @@ The design goals of format strings are as follows: #. Eliminate repetition of identifiers and redundant parentheses. #. Reduce awkward syntax, punctuation characters, and visual noise. #. Improve readability and eliminate mismatch errors, - by prefering named parameters to positional arguments. + by preferring named parameters to positional arguments. #. Avoid need for ``locals()`` and ``globals()`` usage, instead parsing the given string for named parameters, then passing them automatically. [2]_ [3]_ @@ -574,7 +574,7 @@ Rejected Ideas Restricting Syntax to ``str.format()`` Only ''''''''''''''''''''''''''''''''''''''''''' -The common `arguments against`_ support of arbitrary expresssions were: +The common `arguments against`_ support of arbitrary expressions were: #. `YAGNI`_, "You aren't gonna need it." #. The feature is not congruent with historical Python conservatism. @@ -590,7 +590,7 @@ is desired before printing. It can be seen in the `Implementations in Other Languages`_ section that the developer community at large tends to agree. -String interpolation with arbitrary expresssions is becoming an industry +String interpolation with arbitrary expressions is becoming an industry standard in modern languages due to its utility. diff --git a/pep-0503.txt b/pep-0503.txt index b98601e86ba..fa52e536b03 100644 --- a/pep-0503.txt +++ b/pep-0503.txt @@ -76,7 +76,7 @@ In addition to the above, the following constraints are placed on the API: * There may be any other HTML elements on the API pages as long as the required anchor elements exist. -* Repositories **MAY** redirect unnormalized URLs to the cannonical normalized +* Repositories **MAY** redirect unnormalized URLs to the canonical normalized URL (e.g. ``/Foobar/`` may redirect to ``/foobar/``), however clients **MUST NOT** rely on this redirection and **MUST** request the normalized URL. diff --git a/pep-0504.txt b/pep-0504.txt index 7f7c3b0ca97..ca0a763c36a 100644 --- a/pep-0504.txt +++ b/pep-0504.txt @@ -253,7 +253,7 @@ Keeping the module level functions In additional to general backwards compatibility considerations, Python is widely used for educational purposes, and we specifically don't want to -invalidate the wide array of educational material that assumes the availabilty +invalidate the wide array of educational material that assumes the availability of the current ``random`` module API. Accordingly, this proposal ensures that most of the public API can continue to be used not only without modification, but without generating any new warnings. diff --git a/pep-0505.txt b/pep-0505.txt index 8936a34fc0a..371052825c3 100644 --- a/pep-0505.txt +++ b/pep-0505.txt @@ -245,7 +245,7 @@ for error handling, they are no more prone to abuse than ``or`` is. Ternary Operator ~~~~~~~~~~~~~~~~ -Another common way to intialize default values is to use the ternary operator. +Another common way to initialize default values is to use the ternary operator. Here is an excerpt from the popular `Requests package `_:: @@ -303,7 +303,7 @@ from a SQL database and formats it as JSON to send to an HTTP client:: Both ``first_seen`` and ``last_seen`` are allowed to be ``null`` in the database, and they are also allowed to be ``null`` in the JSON response. JSON does not have a native way to represent a ``datetime``, so the server's -contract states that any non-``null`` date is represented as a ISO-8601 string. +contract states that any non-``null`` date is represented as an ISO-8601 string. Note that this code is invalid by PEP-8 standards: several lines are over the line length limit. In fact, *including it in this document* violates the PEP @@ -1097,7 +1097,7 @@ method:: >>> None if user.__coalesce__() else user.first_name.upper() This generalization allows for domain-specific ``null`` objects to be coalesced -just like ``None``. For example the ``pyasn1`` package has a type called +just like ``None``. For example, the ``pyasn1`` package has a type called ``Null`` that represents an ASN.1 ``null``. >>> from pyasn1.type import univ diff --git a/pep-0506.txt b/pep-0506.txt index d57079450e0..1ae224c7bb8 100644 --- a/pep-0506.txt +++ b/pep-0506.txt @@ -135,7 +135,7 @@ This PEP proposes the following functions for the ``secrets`` module: 0 to the given upper limit, ``secrets.randbelow`` [#]_. * A function for comparing text or bytes digests for equality while being - resistent to timing attacks, ``secrets.compare_digest``. + resistant to timing attacks, ``secrets.compare_digest``. The consensus appears to be that there is no need to add a new CSPRNG to the ``random`` module to support these uses, ``SystemRandom`` will be diff --git a/pep-0507.txt b/pep-0507.txt index d1c0f7de2b9..8e0778afbc0 100644 --- a/pep-0507.txt +++ b/pep-0507.txt @@ -227,7 +227,7 @@ the ability to re-use tools out of the box freeing up developer time to actually work on Python itself as well as enabling knowledge sharing between projects. -However if we do need to modify the tooling, Git itself is largely written in +However, if we do need to modify the tooling, Git itself is largely written in C the same as CPython itself. It can also have commands written for it using any language, including Python. GitLab itself is largely written in Ruby and since it is Open Source software, we would have the ability to submit merge diff --git a/pep-0508.txt b/pep-0508.txt index 3ce0d95f2b6..d7b3f7e7582 100644 --- a/pep-0508.txt +++ b/pep-0508.txt @@ -155,7 +155,7 @@ Python distribution names are currently defined in PEP-345 [#pep345]_. Names act as the primary identifier for distributions. They are present in all dependency specifications, and are sufficient to be a specification on their own. However, PyPI places strict restrictions on names - they must match a -case insensitive regex or they won't be accepted. Accordingly in this PEP we +case insensitive regex or they won't be accepted. Accordingly, in this PEP we limit the acceptable values for identifiers to that regex. A full redefinition of name may take place in a future metadata PEP. The regex (run with re.IGNORECASE) is:: @@ -199,7 +199,7 @@ versions it has to be installed as a dependency. This can be expressed as so:: argparse;python_version<"2.7" -A marker expression evalutes to either True or False. When it evaluates to +A marker expression evaluates to either True or False. When it evaluates to False, the dependency specification should be ignored. The marker language is inspired by Python itself, chosen for the ability to @@ -347,7 +347,7 @@ brings together all the currently unspecified components into a specified form. The requirement specifier was adopted from the EBNF in the setuptools -pkg_resources documentation, since we wish to avoid depending on a defacto, vs +pkg_resources documentation, since we wish to avoid depending on a de facto, vs PEP specified, standard. Complete Grammar diff --git a/pep-0510.txt b/pep-0510.txt index f7533a563da..168e0ca52c1 100644 --- a/pep-0510.txt +++ b/pep-0510.txt @@ -70,7 +70,7 @@ PyPy has a ``cpyext`` module which emulates the Python C API but it has worse performances than CPython and does not support the full Python C API. -New features are first developped in CPython. In january 2016, the +New features are first developped in CPython. In January 2016, the latest CPython stable version is 3.5, whereas PyPy only supports Python 2.7 and 3.2, and Pyston only supports Python 2.7. diff --git a/pep-0511.txt b/pep-0511.txt index 860d649b2e6..dc0c108ab5b 100644 --- a/pep-0511.txt +++ b/pep-0511.txt @@ -166,7 +166,7 @@ in pure Python and experiment new optimizations. Some optimizations are easier to implement on the AST like constant folding, but optimizations on the bytecode are still useful. For example, when the AST is compiled to bytecode, useless jumps can be -emited because the compiler is naive and does not try to optimize +emitted because the compiler is naive and does not try to optimize anything. @@ -350,7 +350,7 @@ Example to prepend a new code transformer:: transformers.insert(0, new_cool_transformer) sys.set_code_transformers(transformers) -All AST tranformers are run sequentially (ex: the second transformer +All AST transformers are run sequentially (ex: the second transformer gets the input of the first transformer), and then all bytecode transformers are run sequentially. diff --git a/pep-0512.txt b/pep-0512.txt index 10cb2eac4d6..094f7a33913 100644 --- a/pep-0512.txt +++ b/pep-0512.txt @@ -390,7 +390,7 @@ Handling Misc/NEWS '''''''''''''''''' Traditionally the ``Misc/NEWS`` file [#news-file]_ has been problematic -for changes which spanned Python releases. Often times there will be +for changes which spanned Python releases. Oftentimes there will be merge conflicts when committing a change between e.g., 3.5 and 3.6 only in the ``Misc/NEWS`` file. It's so common, in fact, that the example instructions in the devguide explicitly mention how to diff --git a/pep-0513.txt b/pep-0513.txt index 503088d4937..894f5b3f323 100644 --- a/pep-0513.txt +++ b/pep-0513.txt @@ -58,7 +58,7 @@ companies who have been distributing such widely-portable pre-compiled Python extension modules for Linux -- e.g. Enthought with Canopy [4]_ and Continuum Analytics with Anaconda [5]_. -Building on the compability lessons learned from these companies, we thus +Building on the compatibility lessons learned from these companies, we thus define a baseline ``manylinux1`` platform tag for use by binary Python wheels, and introduce the implementation of preliminary tools to aid in the construction of these ``manylinux1`` wheels. @@ -292,7 +292,7 @@ Compilation of Compliant Wheels The way glibc, libgcc, and libstdc++ manage their symbol versioning means that in practice, the compiler toolchains that most developers use to do their daily work are incapable of building -``manylinux1``-compliant wheels. Therefore we do not attempt to change +``manylinux1``-compliant wheels. Therefore, we do not attempt to change the default behavior of ``pip wheel`` / ``bdist_wheel``: they will continue to generate regular ``linux_*`` platform tags, and developers who wish to use them to generate ``manylinux1``-tagged wheels will @@ -552,7 +552,7 @@ system-installed packages. However, such extensions would require substantially more work than this proposal, and still might not be appreciated by package developers who would prefer not to have to maintain multiple build environments and build multiple wheels in order to cover all the common Linux distributions. -Therefore we consider such proposals to be out-of-scope for this PEP. +Therefore, we consider such proposals to be out-of-scope for this PEP. Future updates diff --git a/pep-0516.txt b/pep-0516.txt index 756f09e6ab6..6d275425593 100644 --- a/pep-0516.txt +++ b/pep-0516.txt @@ -38,9 +38,9 @@ easy-install. As PEP-426 [#pep426]_ is draft, we cannot utilise the metadata format it defined. However PEP-427 wheels are in wide use and fairly well specified, so we have adopted the METADATA format from that for specifying distribution -dependencies and general project metadata. PEP-0508 [#pep508] provides a self -contained language for describing a dependency, which we encapsulate in a thin -JSON schema to describe bootstrap dependencies. +dependencies and general project metadata. PEP-0508 [#pep508] provides a +self-contained language for describing a dependency, which we encapsulate in a +thin JSON schema to describe bootstrap dependencies. Since Python sdists specified in PEP-0314 [#pep314] are also source trees, this PEP is updating the definition of sdists. @@ -115,7 +115,7 @@ Processes will be run with the current working directory set to the root of the source tree. When run, processes should not read from stdin - while pip currently runs -build systems with stdin connected to it's own stdin, stdout and stderr are +build systems with stdin connected to its own stdin, stdout and stderr are redirected and no communication with the user is possible. As usual with processes, a non-zero exit status indicates an error. @@ -236,7 +236,7 @@ requirements (e.g. setuptools_scm) and only install other versions on version conflicts or missing dependencies. However its likely that better consistency can be created by always isolation builds and using only the specified dependencies. -However there are nuanced problems there - such as how can users force the +However, there are nuanced problems there - such as how can users force the avoidance of a bad version of a build requirement which meets some packages dependencies. Future PEPs may tackle this problem, but it is not currently in scope - it does not affect the metadata required to coordinate between build @@ -258,7 +258,7 @@ The sequence for upgrading either of schemas in a new PEP will be: introduced support for the new schema version. The *same* process will take place for the initial deployment of this PEP:- -the propogation of the capability to use this PEP without a `setuptools shim`_ +the propagation of the capability to use this PEP without a `setuptools shim`_ will be largely gated by the adoption rate of the first version of pip that supports it. @@ -367,7 +367,7 @@ The basic heuristic for the design has been to focus on introducing an abstraction without requiring development not strictly tied to the abstraction. Where the gap is small to improvements, or the cost of using the existing interface is very high, then we've taken on having the improvement as -a dependency, but otherwise defered such to future iterations. +a dependency, but otherwise deferred such to future iterations. We chose wheel METADATA files rather than defining a new specification, because pip can already handle wheel .dist-info directories which encode all @@ -435,7 +435,7 @@ References .. [#pip] pip, the recommended installer for Python packages (http://pip.readthedocs.org/en/stable/) -.. [#setuptools] setuptools, the defacto Python package build system +.. [#setuptools] setuptools, the de facto Python package build system (https://pythonhosted.org/setuptools/) .. [#flit] flit, a simple way to put packages in PyPI diff --git a/pep-0518.txt b/pep-0518.txt index c62e3199cbf..c2b275261d1 100644 --- a/pep-0518.txt +++ b/pep-0518.txt @@ -251,7 +251,7 @@ Other file formats Several other file formats were put forward for consideration, all rejected for various reasons. Key requirements were that the format be editable by human beings and have an implementation that can be -vendored easily by projects. This outright exluded certain formats +vendored easily by projects. This outright excluded certain formats like XML which are not friendly towards human beings and were never seriously discussed. diff --git a/pep-0520.txt b/pep-0520.txt index 409f7dacd4d..3b383dec64d 100644 --- a/pep-0520.txt +++ b/pep-0520.txt @@ -209,7 +209,7 @@ making the common case simpler. However, leaving dunder names out of ``__definition_order__`` means that their place in the definition order would be unrecoverably lost. -Dropping dunder names by default may inadvertantly cause problems for +Dropping dunder names by default may inadvertently cause problems for classes that use dunder names unconventionally. In this case it's better to play it safe and preserve *all* the names from the class definition. This isn't a big problem since it is easy to filter out @@ -234,7 +234,7 @@ Why None instead of an empty tuple? A key objective of adding ``__definition_order__`` is to preserve information in class definitions which was lost prior to this PEP. One consequence is that ``__definition_order__`` implies an original -class definition. Using ``None`` allows us to clearly distinquish +class definition. Using ``None`` allows us to clearly distinguish classes that do not have a definition order. An empty tuple clearly indicates a class that came from a definition statement but did not define any attributes there. @@ -394,7 +394,7 @@ would be that at compile-time it would not be practical to preserve definition order for attributes that are set dynamically in the class body (e.g. ``locals()[name] = value``). However, they should still be reflected in the definition order. One -posible resolution would be to require class authors to manually +possible resolution would be to require class authors to manually set ``__definition_order__`` if they define any class attributes dynamically. diff --git a/pep-0523.txt b/pep-0523.txt index 579ef207e2e..3c52f421be6 100644 --- a/pep-0523.txt +++ b/pep-0523.txt @@ -108,7 +108,7 @@ the field has not been previously set by someone else. Expanding ``PyInterpreterState`` -------------------------------- -The entrypoint for the frame evalution function is per-interpreter:: +The entrypoint for the frame evaluation function is per-interpreter:: // Same type signature as PyEval_EvalFrameEx(). typedef PyObject* (__stdcall *PyFrameEvalFunction)(PyFrameObject*, int); @@ -277,7 +277,7 @@ Allow ``eval_frame`` to be ``NULL`` Currently the frame evaluation function is expected to always be set. It could very easily simply default to ``NULL`` instead which would signal to use ``PyEval_EvalFrameDefault()``. The current proposal of -not special-casing the field seemed the most straight-forward, but it +not special-casing the field seemed the most straightforward, but it does require that the field not accidentally be cleared, else a crash may occur. diff --git a/pep-0754.txt b/pep-0754.txt index bb506ef6ef2..fcb2f9300ec 100644 --- a/pep-0754.txt +++ b/pep-0754.txt @@ -137,13 +137,13 @@ Functions --------- isNaN(value) - Determine if the argument is a IEEE 754 NaN (Not a Number) value. + Determine if the argument is an IEEE 754 NaN (Not a Number) value. isPosInf(value) - Determine if the argument is a IEEE 754 positive infinity value. + Determine if the argument is an IEEE 754 positive infinity value. isNegInf(value) - Determine if the argument is a IEEE 754 negative infinity value. + Determine if the argument is an IEEE 754 negative infinity value. isFinite(value) Determine if the argument is a finite IEEE 754 value (i.e., is diff --git a/pep-3100.txt b/pep-3100.txt index babfc567c7b..6c88e981ae7 100644 --- a/pep-3100.txt +++ b/pep-3100.txt @@ -78,7 +78,7 @@ Core language * Comparisons other than ``==`` and ``!=`` between disparate types will raise an exception unless explicitly supported by the type [6]_ [done] * floats will not be acceptable as arguments in place of ints for operations - where floats are inadvertantly accepted (PyArg_ParseTuple() i & l formats) + where floats are inadvertently accepted (PyArg_ParseTuple() i & l formats) * Remove from ... import * at function scope. [done] This means that functions can always be optimized and support for unoptimized functions can go away. * Imports [#pep328]_ @@ -159,7 +159,7 @@ To be removed: * ``basestring.find()`` and ``basestring.rfind()``; use ``basestring.index()`` or ``basestring.[r]partition()`` or - or ``basestring.rindex()`` in a try/except block??? [13]_ [UNLIKELY] + ``basestring.rindex()`` in a try/except block??? [13]_ [UNLIKELY] * ``file.xreadlines()`` method [#file-object]_ [done] * ``dict.setdefault()``? [15]_ [UNLIKELY] * ``dict.has_key()`` method; use ``in`` operator [done] diff --git a/pep-3108.txt b/pep-3108.txt index 85bf62ffb6b..0275e0342a1 100644 --- a/pep-3108.txt +++ b/pep-3108.txt @@ -530,7 +530,7 @@ for what the module is meant for. * bsddb185 [done] - + Superceded by bsddb3 + + Superseded by bsddb3 + Not built by default. + Documentation specifies that the "module should never be used directly in new code". @@ -629,7 +629,7 @@ for what the module is meant for. * urllib [done] - + Superceded by urllib2. + + Superseded by urllib2. + Functionality unique to urllib will be kept in the urllib package. @@ -651,7 +651,7 @@ Over the years, certain modules have become a heavy burden upon python-dev to maintain. In situations like this, it is better for the module to be given to the community to maintain to free python-dev to focus more on language support and other modules in the standard -library that do not take up a undue amount of time and effort. +library that do not take up an undue amount of time and effort. * bsddb3 @@ -984,7 +984,7 @@ statement and none of the rest of the code needs to be touched. This will be accomplished by using the ``as`` keyword in import statements to bind in the module namespace to the old name while importing based on the new name (when the keyword is not already used, otherwise the -re-assigned name should be left alone and only the module that is +reassigned name should be left alone and only the module that is imported needs to be changed). The ``fix_imports`` fixer is an example of how to approach this. diff --git a/pep-3118.txt b/pep-3118.txt index 10269dc9790..14a24e92444 100644 --- a/pep-3118.txt +++ b/pep-3118.txt @@ -654,10 +654,10 @@ Character Description '&' specific pointer (prefix before another character) 'T{}' structure (detailed layout inside {}) '(k1,k2,...,kn)' multi-dimensional array of whatever follows -':name:' optional name of the preceeding element +':name:' optional name of the preceding element 'X{}' pointer to a function (optional function signature inside {} with any return value - preceeded by -> and placed at the end) + preceded by -> and placed at the end) ================ =========== The struct module will be changed to understand these as well and @@ -680,7 +680,7 @@ default endian is '@' which means native data-types and alignment. If un-aligned, native data-types are requested, then the endian specification is '^'. -According to the struct-module, a number can preceed a character +According to the struct-module, a number can precede a character code to specify how many of that type there are. The ``(k1,k2,...,kn)`` extension also allows specifying if the data is supposed to be viewed as a (C-style contiguous, last-dimension @@ -740,7 +740,7 @@ Nested array Note, that in the last example, the C-structure compared against is intentionally a 1-d array and not a 2-d array data[16][4]. The reason for this is to avoid the confusions between static multi-dimensional -arrays in C (which are layed out contiguously) and dynamic +arrays in C (which are laid out contiguously) and dynamic multi-dimensional arrays which use the same syntax to access elements, data[0][1], but whose memory is not necessarily contiguous. The struct-syntax *always* uses contiguous memory and the @@ -852,7 +852,7 @@ This example shows how an image object that uses contiguous lines might expose i }; "lines" points to malloced 1-D array of ``(struct rgba*)``. Each pointer -in THAT block points to a seperately malloced array of ``(struct rgba)``. +in THAT block points to a separately malloced array of ``(struct rgba)``. In order to access, say, the red value of the pixel at x=30, y=50, you'd use "lines[50][30].r". diff --git a/pep-3127.txt b/pep-3127.txt index 6df1dddd47f..4485bd177a5 100644 --- a/pep-3127.txt +++ b/pep-3127.txt @@ -134,7 +134,7 @@ instead of '0'. In 2.6, alternate octal formatting will continue to add only '0'. In neither 2.6 nor 3.0 will the % operator support binary output. This is because binary output is already supported by PEP 3101 -(str.format), which is the prefered string formatting +(str.format), which is the preferred string formatting method. @@ -497,10 +497,10 @@ References .. [3] The Representation of Numbers, Jiajie Zhang and Donald A. Norman (http://acad88.sahs.uth.tmc.edu/research/publications/Number-Representation.pdf) -.. [4] ENIAC page at wikipedia +.. [4] ENIAC page at Wikipedia (http://en.wikipedia.org/wiki/ENIAC) -.. [5] BCD page at wikipedia +.. [5] BCD page at Wikipedia (http://en.wikipedia.org/wiki/Binary-coded_decimal) Copyright diff --git a/pep-3131.txt b/pep-3131.txt index 691662f312e..ab56132a718 100644 --- a/pep-3131.txt +++ b/pep-3131.txt @@ -109,7 +109,7 @@ ASCII-only identifiers, and SHOULD use English words wherever feasible aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are -not based on the latin alphabet MUST provide a latin transliteration +not based on the Latin alphabet MUST provide a Latin transliteration of their names. As an option, this specification can be applied to Python 2.x. In diff --git a/pep-3134.txt b/pep-3134.txt index 2684a1c9489..2d24899adf7 100644 --- a/pep-3134.txt +++ b/pep-3134.txt @@ -61,9 +61,9 @@ History exception with more information. Brett Cannon [2] brought up chained exceptions again in June 2003, prompting a long discussion. - Greg Ewing [3] identified the case of an exception occuring in a + Greg Ewing [3] identified the case of an exception occurring in a 'finally' block during unwinding triggered by an original exception, - as distinct from the case of an exception occuring in an 'except' + as distinct from the case of an exception occurring in an 'except' block that is handling the original exception. Greg Ewing [4] and Guido van Rossum [5], and probably others, have diff --git a/pep-3145.txt b/pep-3145.txt index b2015f855c0..df2028fafba 100644 --- a/pep-3145.txt +++ b/pep-3145.txt @@ -71,7 +71,7 @@ Reference Implementation: There are two base functions that have been added to the subprocess.Popen class: Popen.send and Popen._recv, each with two separate implementations, - one for Windows and one for Unix based systems. The Windows + one for Windows and one for Unix-based systems. The Windows implementation uses ctypes to access the functions needed to control pipes in the kernel 32 DLL in an asynchronous manner. On Unix based systems, the Python interface for file control serves the same purpose. The diff --git a/pep-3153.txt b/pep-3153.txt index a50f4c5361d..bc7ba4b05b9 100644 --- a/pep-3153.txt +++ b/pep-3153.txt @@ -237,7 +237,7 @@ However, there appear to be a few problems with this. First of all, there is a conceptual problem. A generator, in a sense, is "passive". It needs to be told, through a method call, to take action. A producer is "active": it initiates those method calls. A -real producer has a symmetric relationship with it's consumer. In the +real producer has a symmetric relationship with its consumer. In the case of a generator-turned-producer, only the consumer would have a reference, and the producer is blissfully unaware of the consumer's existence. diff --git a/pep-3156.txt b/pep-3156.txt index 0e73216e048..ec14cb1219b 100644 --- a/pep-3156.txt +++ b/pep-3156.txt @@ -608,7 +608,7 @@ use a different transport and protocol interface. or otherwise) specifies a ``verify_mode`` of ``CERT_REQUIRED`` or ``CERT_OPTIONAL``, if a hostname is given, immediately after a successful handshake ``ssl.match_hostname(peercert, hostname)`` is - called, and if this raises an exception the conection is closed. + called, and if this raises an exception the connection is closed. (To avoid this behavior, pass in an SSL context that has ``verify_mode`` set to ``CERT_NONE``. But this means you are not secure, and vulnerable to for example man-in-the-middle attacks.) @@ -1449,7 +1449,7 @@ that ``process_exited()`` is called either before or after ``pipe_connection_lost()``. For example, if the subprocess creates a sub-subprocess that shares its stdin/stdout/stderr and then itself exits, ``process_exited()`` may be called while all the pipes are -still open. On the other hand when the subprocess closes its +still open. On the other hand, when the subprocess closes its stdin/stdout/stderr but does not exit, ``pipe_connection_lost()`` may be called for all three pipes without ``process_exited()`` being called. If (as is the more common case) the subprocess exits and diff --git a/pep-3333.txt b/pep-3333.txt index c7ac0d5f432..3b8009a6ff5 100644 --- a/pep-3333.txt +++ b/pep-3333.txt @@ -17,7 +17,7 @@ Preface for Readers of PEP \333 This is an updated version of PEP 333, modified slightly to improve usability under Python 3, and to incorporate several long-standing -de-facto amendments to the WSGI protocol. (Its code samples have +de facto amendments to the WSGI protocol. (Its code samples have also been ported to Python 3.) While for procedural reasons [6]_, this must be a distinct PEP, no @@ -394,7 +394,7 @@ are more stringent than for a "pure" server or application, and these points will be noted in the specification. Here is a (tongue-in-cheek) example of a middleware component that -converts ``text/plain`` responses to pig latin, using Joe Strout's +converts ``text/plain`` responses to pig Latin, using Joe Strout's ``piglatin.py``. (Note: a "real" middleware component would probably use a more robust way of checking the content type, and should also check for a content encoding. Also, this simple @@ -694,7 +694,7 @@ Variable Value (On platforms where the ``str`` type is unicode, the error stream **should** accept and log - arbitary unicode without raising an error; it + arbitrary unicode without raising an error; it is allowed, however, to substitute characters that cannot be rendered in the stream's encoding.) @@ -1570,7 +1570,7 @@ Questions and Answers chooses *not* to use a dictionary, then there will be interoperability problems despite that server's "conformance" to spec. Therefore, making a dictionary mandatory simplifies the - specification and guarantees interoperabilty. + specification and guarantees interoperability. Note that this does not prevent server or framework developers from offering specialized services as custom variables *inside* the diff --git a/pep0/pep.py b/pep0/pep.py index dcb544eb1e7..c287c6b09aa 100644 --- a/pep0/pep.py +++ b/pep0/pep.py @@ -83,7 +83,7 @@ def __init__(self, author_and_email_tuple): elif self.first == "Just": self.nick = "JvR" else: - raise ValueError("unkown van Rossum %r!" % self) + raise ValueError("unknown van Rossum %r!" % self) self.last_first += " (%s)" % (self.nick,) else: self.nick = self.last