From 6a54632396420db9c21d279ec9c2a708d4d53e6b Mon Sep 17 00:00:00 2001 From: Dimitri Papadopoulos <3234522+DimitriPapadopoulos@users.noreply.github.com> Date: Fri, 17 Sep 2021 01:21:49 +0200 Subject: [PATCH 1/2] Typos found by codespell --- pep-0002.txt | 2 +- pep-0042.txt | 2 +- pep-0101.txt | 2 +- pep-0214.txt | 2 +- pep-0252.txt | 2 +- pep-0287.txt | 2 +- pep-0340.txt | 2 +- pep-0367.txt | 2 +- pep-0372.txt | 2 +- pep-0374.txt | 2 +- pep-0389.txt | 2 +- pep-0400.txt | 4 ++-- pep-0423.txt | 2 +- pep-0425.txt | 4 ++-- pep-0439.txt | 10 +++++----- pep-0442.txt | 2 +- pep-0447.txt | 4 ++-- pep-0452.txt | 2 +- pep-0454.txt | 6 +++--- pep-0457.txt | 2 +- pep-0467.txt | 2 +- pep-0475.txt | 2 +- pep-0485.txt | 2 +- pep-0490.txt | 2 +- pep-0509.txt | 2 +- pep-0510.txt | 4 ++-- pep-0511.txt | 2 +- pep-0519.txt | 2 +- pep-0523.txt | 2 +- pep-0525.txt | 2 +- pep-0531.txt | 2 +- pep-0554.rst | 6 +++--- pep-0575.rst | 4 ++-- pep-0587.rst | 2 +- pep-0605.rst | 2 +- pep-0610.rst | 2 +- pep-0612.rst | 2 +- pep-0633.rst | 2 +- pep-0634.rst | 2 +- pep-0637.rst | 2 +- pep-0642.rst | 10 +++++----- pep-0646.rst | 2 +- pep-0651.rst | 2 +- pep-0652.rst | 4 ++-- pep-0653.rst | 8 ++++---- pep-0654.rst | 2 +- pep-0656.rst | 2 +- pep-0659.rst | 6 +++--- pep-0660.rst | 2 +- pep-0662.rst | 4 ++-- pep-0663.txt | 4 ++-- pep-0665.rst | 2 +- pep-3101.txt | 4 ++-- pep-3110.txt | 2 +- pep-3116.txt | 2 +- pep-3132.txt | 2 +- pep-3135.txt | 2 +- pep-3141.txt | 2 +- pep-3149.txt | 4 ++-- pep-3150.txt | 2 +- pep-3156.txt | 2 +- pep_sphinx_extensions/pep_theme/static/style.css | 2 +- 62 files changed, 89 insertions(+), 89 deletions(-) diff --git a/pep-0002.txt b/pep-0002.txt index bf8ffdd8d5e..b4793217988 100644 --- a/pep-0002.txt +++ b/pep-0002.txt @@ -67,7 +67,7 @@ Maintainer(s) All contributions to the standard library need one or more maintainers. This can be an individual, but it is frequently a group of people such as the XML- SIG. Groups may subdivide maintenance -tasks among themselves. One ore more maintainers shall be the *head +tasks among themselves. One or more maintainers shall be the *head maintainer* (usually this is also the main developer). Head maintainers are convenient people the integrators can address if they want to resolve specific issues, such as the ones detailed later in diff --git a/pep-0042.txt b/pep-0042.txt index 6e86cf6f74f..08ba663f95e 100644 --- a/pep-0042.txt +++ b/pep-0042.txt @@ -106,7 +106,7 @@ Standard Library handler, it returns "". It would be better to make it raise an exception (corresponding to EINTR) or to restart. But these changes would have to applied to all places that can do blocking - interruptable I/O. So it's a big project. + interruptible I/O. So it's a big project. https://bugs.python.org/issue210599 diff --git a/pep-0101.txt b/pep-0101.txt index 4303d637648..7b8528e1073 100644 --- a/pep-0101.txt +++ b/pep-0101.txt @@ -534,7 +534,7 @@ the main repo. you will now need to manual remove each blurb entry from the ``Misc/NEWS.d/next`` directory that was cherry-picked into the release you are working on since that blurb entry - is now captured in the merged x.y.z.rst fils for the new + is now captured in the merged x.y.z.rst file for the new release. Otherwise, the blurb entry will appear twice in the `changelog.html` file, once under `Python next` and again under `x.y.z`. diff --git a/pep-0214.txt b/pep-0214.txt index 65b69ac7ba8..05050689bf5 100644 --- a/pep-0214.txt +++ b/pep-0214.txt @@ -193,7 +193,7 @@ symbol. necessary! Of course you want the file to be an arbitrary expression, not just a single word. (You definitely want to be able to write ``print >>sys.stderr``.) Without the expression the - parser would't be able to distinguish where that expression ends + parser wouldn't be able to distinguish where that expression ends and where the next one begins, e.g. :: diff --git a/pep-0252.txt b/pep-0252.txt index 15681f98ac3..ed250ec03ea 100644 --- a/pep-0252.txt +++ b/pep-0252.txt @@ -623,7 +623,7 @@ this situation substantially. - Modification for dynamic types: step 1 and 3 look in the dictionary of the type and all its base classes (in MRO - sequence, or couse). + sequence, or course). Discussion diff --git a/pep-0287.txt b/pep-0287.txt index 862dd66d331..d04c0f23205 100644 --- a/pep-0287.txt +++ b/pep-0287.txt @@ -271,7 +271,7 @@ SText idea, addressing all of the problems listed above. Specification ============= -The specification and user documentaton for reStructuredText is +The specification and user documentation for reStructuredText is quite extensive. Rather than repeating or summarizing it all here, links to the originals are provided. diff --git a/pep-0340.txt b/pep-0340.txt index b75fdc06f2d..f6739ee5607 100644 --- a/pep-0340.txt +++ b/pep-0340.txt @@ -270,7 +270,7 @@ Alternatives Considered and Rejected an entirely different API than the for-loop, to differentiate between the two. A generator would have to be wrapped in a decorator to make it support the block API. IMO this adds more - complexity with very little benefit; and we can't relly deny + complexity with very little benefit; and we can't really deny that the block-statement is conceptually a loop -- it supports break and continue, after all. diff --git a/pep-0367.txt b/pep-0367.txt index e62e23219e8..718698c53a4 100644 --- a/pep-0367.txt +++ b/pep-0367.txt @@ -481,7 +481,7 @@ The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit -invokation of a super instance upon a class and instance. +invocation of a super instance upon a class and instance. This proposal relies on sys._getframe(), which is not appropriate for anything except a prototype implementation. diff --git a/pep-0372.txt b/pep-0372.txt index a63ca5391d5..ffd102fc0dd 100644 --- a/pep-0372.txt +++ b/pep-0372.txt @@ -249,7 +249,7 @@ What are the trade-offs of the possible underlying data structures? the code a little bit more complex. All of the basic operations are O(1) but the constant factor is increased for __setitem__() and __delitem__() meaning that every use case will have to pay for this speedup (since all - buildup go through __setitem__). Also, the first traveral incurs a + buildup go through __setitem__). Also, the first traversal incurs a one-time ``O(n log n)`` sorting cost. The storage costs are double that for the sorted-list-of-keys approach. diff --git a/pep-0374.txt b/pep-0374.txt index b05c2245501..e41ffbfdbfe 100644 --- a/pep-0374.txt +++ b/pep-0374.txt @@ -1443,7 +1443,7 @@ 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 hindrance for people who lack commit -privileges. But DVCSs have no such limitiation as anyone can create a +privileges. But DVCSs have no such limitation 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 anyone to have the same workflow as the core developers was the key diff --git a/pep-0389.txt b/pep-0389.txt index 900feb84e08..19f5d7d206b 100644 --- a/pep-0389.txt +++ b/pep-0389.txt @@ -42,7 +42,7 @@ a valuable addition to the Python libraries. Why aren't getopt and optparse enough? ====================================== -One argument against adding argparse is that thare are "already two +One argument against adding argparse is that there are "already two different option parsing modules in the standard library" [9]_. The following is a list of features provided by argparse but not present in getopt or optparse: diff --git a/pep-0400.txt b/pep-0400.txt index e2fa023156c..23fc804db87 100644 --- a/pep-0400.txt +++ b/pep-0400.txt @@ -192,7 +192,7 @@ file-like objects (same API). codecs.open() was the only way to open a text file in Unicode mode until Python 2.6. Many Python 2 programs uses this function. Removing codecs.open() implies more work to port programs from Python 2 to -Python 3, especially projets using the same code base for the two +Python 3, especially projetcs using the same code base for the two Python versions (without using 2to3 program). codecs.open() is kept for backward compatibility with Python 2. @@ -201,7 +201,7 @@ codecs.open() is kept for backward compatibility with Python 2. Deprecate StreamReader and StreamWriter ''''''''''''''''''''''''''''''''''''''' -Instanciating StreamReader or StreamWriter must emit a DeprecationWarning in +Instantiating StreamReader or StreamWriter must emit a DeprecationWarning in Python 3.3. Defining a subclass doesn't emit a DeprecationWarning. codecs.open() will be changed to reuse the builtin open() function diff --git a/pep-0423.txt b/pep-0423.txt index a9b34bb9ccb..43dd9c6b604 100644 --- a/pep-0423.txt +++ b/pep-0423.txt @@ -561,7 +561,7 @@ Actions: * if you use the `default convention <#use-standard-pattern-for-community-contributions>`_, then this - document should be enough. Don't reapeat it. You may reference + document should be enough. Don't repeat it. You may reference it. * else, tell users about custom conventions in project's diff --git a/pep-0425.txt b/pep-0425.txt index 66e2942954c..3ae109e5a49 100644 --- a/pep-0425.txt +++ b/pep-0425.txt @@ -114,7 +114,7 @@ the CPython 3.3 ABI with debugging. The CPython stable ABI is `abi3` as in the shared library suffix. Implementations with a very unstable ABI may use the first 6 bytes (as -8 base64-encoded characters) of the SHA-256 hash of ther source code +8 base64-encoded characters) of the SHA-256 hash of their source code revision and compiler flags, etc, but will probably not have a great need to distribute binary distributions. Each implementation's community may decide how to best use the ABI tag. @@ -226,7 +226,7 @@ What tag do I use if my distribution uses a feature exclusive to the newest vers Why isn't there a `.` in the Python version number? CPython has lasted 20+ years without a 3-digit major release. This should continue for some time. Other implementations may use _ as - a delimeter, since both - and . delimit the surrounding filename. + a delimiter, since both - and . delimit the surrounding filename. Why normalise hyphens and other non-alphanumeric characters to underscores? To avoid conflicting with the "." and "-" characters that separate diff --git a/pep-0439.txt b/pep-0439.txt index d1a2be14576..beb804e7aab 100644 --- a/pep-0439.txt +++ b/pep-0439.txt @@ -17,7 +17,7 @@ Resolution: https://mail.python.org/pipermail/distutils-sig/2013-August/022527.h Abstract ======== -This PEP proposes the inclusion of a pip boostrap executable in the +This PEP proposes the inclusion of a pip bootstrap executable in the Python installation to simplify the use of 3rd-party modules by Python users. @@ -91,7 +91,7 @@ and virtualenv. Once installed, the pip command proceeds as normal. Once the bootstrap process is complete the "pip3" command is no longer the bootstrap but rather the full pip command. -A boostrap is used in the place of a the full pip code so that we don't have +A bootstrap is used in the place of a the full pip code so that we don't have to bundle pip and also pip is upgradeable outside of the regular Python upgrade timeframe and processes. @@ -110,7 +110,7 @@ The bootstrap process will proceed as follows: called "pip3". 2. The user will invoke a pip command, typically "pip3 install ", for example "pip3 install Django". -3. The boostrap script will attempt to import the pip implementation. +3. The bootstrap script will attempt to import the pip implementation. If this succeeds, the pip command is processed normally. Stop. 4. On failing to import the pip implementation the bootstrap notifies the user that it needs to "install pip". It will ask the user whether it @@ -140,11 +140,11 @@ CA certificate check performed. This facility will be present in Python 3.4+ using Operating System certificates (see PEP XXXX). Beyond those arguments controlling index location and download -options, the "pip3" boostrap command may support further standard pip +options, the "pip3" bootstrap command may support further standard pip options for verbosity, quietness and logging. The "pip3" command will support two new command-line options that are used -in the boostrapping, and otherwise ignored. They control where the pip +in the bootstrapping, and otherwise ignored. They control where the pip implementation is installed: ``--bootstrap`` diff --git a/pep-0442.txt b/pep-0442.txt index a43afebaa2b..10792a74ef6 100644 --- a/pep-0442.txt +++ b/pep-0442.txt @@ -34,7 +34,7 @@ Reference Weak reference A directional link from an object to another, which doesn't keep - alive its target. This PEP focusses on non-weak references. + alive its target. This PEP focuses on non-weak references. Reference cycle A cyclic subgraph of directional links between objects, which keeps diff --git a/pep-0447.txt b/pep-0447.txt index 6db8cbaa102..a602f1237d2 100644 --- a/pep-0447.txt +++ b/pep-0447.txt @@ -40,7 +40,7 @@ to:: return NotFound -The default implemention of ``__getdescriptor__`` looks in the class +The default implementation of ``__getdescriptor__`` looks in the class dictionary:: class type: @@ -669,7 +669,7 @@ Discussion threads * The initial version of the PEP was send with Message-ID `<75030FAC-6918-4E94-95DA-67A88D53E6F5@mac.com>`_ -* Further discusion starting at a message with +* Further discussion starting at a message with Message-ID `<5BB87CC4-F31B-4213-AAAC-0C0CE738460C@mac.com>`_ * And more discussion starting at message with diff --git a/pep-0452.txt b/pep-0452.txt index 4362c86e332..cdddd5ce5f2 100644 --- a/pep-0452.txt +++ b/pep-0452.txt @@ -236,7 +236,7 @@ Changes * 2001-09-20: Removed ``reset()`` method completely. * 2001-09-28: Set ``digest_size`` to ``None`` for variable-size hashes. * 2013-08-15: Added ``block_size`` and ``name`` attributes; clarified that - 'string' actually referes to bytes-like objects. + 'string' actually refers to bytes-like objects. Acknowledgements diff --git a/pep-0454.txt b/pep-0454.txt index e7e35e360b5..895bced9bbb 100644 --- a/pep-0454.txt +++ b/pep-0454.txt @@ -78,7 +78,7 @@ implemented in the PySizer project in 2005. PySizer was implemented differently: the traceback was stored in frame objects and some Python types were linked the trace with the name of object type. PySizer patch on CPython adds an overhead on performances and memory footprint, even if -the PySizer was not used. tracemalloc attachs a traceback to the +the PySizer was not used. tracemalloc attaches a traceback to the underlying layer, to memory blocks, and has no overhead when the module is not tracing memory allocations. @@ -313,7 +313,7 @@ Snapshot All inclusive filters are applied at once, a trace is ignored if no inclusive filters match it. A trace is ignored if at least one - exclusive filter matchs it. + exclusive filter matches it. ``load(filename)`` classmethod: @@ -526,7 +526,7 @@ Prior Work `_: Python Memory Usage Analyzer developed by John A Meinel since 2009 * `gdb-heap `_: gdb script written in - Python by Dave Malcom (2010-2011) to analyze the usage of the heap memory + Python by Dave Malcolm (2010-2011) to analyze the usage of the heap memory * `memory_profiler `_: written by Fabian Pedregosa (2011-2013) * `caulk `_: written by Ben Timby in 2012 diff --git a/pep-0457.txt b/pep-0457.txt index 7b396ece546..6e4d2e9fb28 100644 --- a/pep-0457.txt +++ b/pep-0457.txt @@ -45,7 +45,7 @@ variadic ``*args`` parameter. However, there is no Python syntax to specify accepting a specific number of positional-only parameters. Put another way, there are many builtin functions whose signatures are simply not -expressable with Python syntax. +expressible with Python syntax. This PEP proposes a notation for such signatures that could form the basis of a backwards-compatible syntax that should permit implementing diff --git a/pep-0467.txt b/pep-0467.txt index b37d5cda710..666d7218558 100644 --- a/pep-0467.txt +++ b/pep-0467.txt @@ -116,7 +116,7 @@ order functions like ``map``. These new methods intentionally do NOT offer the same level of general integer support as the existing ``int.to_bytes`` conversion method, which allows -arbitrarily large integers to be converted to arbitarily long bytes objects. The +arbitrarily large integers to be converted to arbitrarily long bytes objects. The restriction to only accept positive integers that fit in a single byte means that no byte order information is needed, and there is no need to handle negative numbers. The documentation of the new methods will refer readers to diff --git a/pep-0475.txt b/pep-0475.txt index ac442bea4d6..3f812b90ba9 100644 --- a/pep-0475.txt +++ b/pep-0475.txt @@ -399,7 +399,7 @@ Closed issues: `_ * `subprocess: Popen.communicate() doesn't handle EINTR in some cases `_ -* `multiprocessing.util._eintr_retry doen't recalculate timeouts +* `multiprocessing.util._eintr_retry doesn't recalculate timeouts `_ * `file readline, readlines & readall methods can lose data on EINTR `_ diff --git a/pep-0485.txt b/pep-0485.txt index e77fd26a1c1..09fb7dcf132 100644 --- a/pep-0485.txt +++ b/pep-0485.txt @@ -115,7 +115,7 @@ 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 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 +duck typing. Rather, the values passed into the function will be converted to the float type before the calculation is performed. Passing in types (or values) that cannot be converted to floats will raise an appropriate Exception (TypeError, ValueError, or OverflowError). diff --git a/pep-0490.txt b/pep-0490.txt index e96c2c4678f..3105f1b3a2d 100644 --- a/pep-0490.txt +++ b/pep-0490.txt @@ -168,7 +168,7 @@ exceptions. The reference cycle can now be fixed with the new ``traceback.TracebackException`` object introduced in Python 3.5. It -stores informations required to format a full textual traceback without +stores information required to format a full textual traceback without storing local variables. The ``asyncio`` is impacted by the reference cycle issue. This module diff --git a/pep-0509.txt b/pep-0509.txt index aa59d5a5da9..b9e94a012b7 100644 --- a/pep-0509.txt +++ b/pep-0509.txt @@ -310,7 +310,7 @@ Expose the version at Python level as a read-only __version__ property The first version of the PEP proposed to expose the dictionary version as a read-only ``__version__`` property at Python level, and also to add -the property to ``collections.UserDict`` (since this type must mimick +the property to ``collections.UserDict`` (since this type must mimic the ``dict`` API). There are multiple issues: diff --git a/pep-0510.txt b/pep-0510.txt index 9f54fc7f31e..70746c9ef7f 100644 --- a/pep-0510.txt +++ b/pep-0510.txt @@ -250,7 +250,7 @@ function:: # use the specialized code return specialized_code elif check == 1: - # a guard failed temporarely: + # a guard failed temporarily: # try the next specialized code index += 1 else: @@ -315,7 +315,7 @@ The ``init()`` function initializes a guard: The ``check()`` function checks a guard: * Return ``0`` on success -* Return ``1`` if the guard failed temporarely +* Return ``1`` if the guard failed temporarily * Return ``2`` if the guard will always fail: the specialized code must be removed * Raise an exception and return ``-1`` on error diff --git a/pep-0511.txt b/pep-0511.txt index d54546a448d..29282b95c8b 100644 --- a/pep-0511.txt +++ b/pep-0511.txt @@ -514,7 +514,7 @@ Output:: AST transformer --------------- -Similary to the bytecode transformer example, the AST transformer also +Similarly to the bytecode transformer example, the AST transformer also replaces all strings with ``"Ni! Ni! Ni!"``:: import ast diff --git a/pep-0519.txt b/pep-0519.txt index 20df78436e9..af3583c5d8d 100644 --- a/pep-0519.txt +++ b/pep-0519.txt @@ -518,7 +518,7 @@ References .. [#python-dev-archive] The python-dev mailing list archive (https://mail.python.org/pipermail/python-dev/) -.. [#libc-open] ``open()`` documention for the C standard library +.. [#libc-open] ``open()`` documentation for the C standard library (http://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html) .. [#pathlib] The ``pathlib`` module diff --git a/pep-0523.txt b/pep-0523.txt index 3219661e2a2..43c43f4193c 100644 --- a/pep-0523.txt +++ b/pep-0523.txt @@ -245,7 +245,7 @@ It should be mentioned that the Pyston team was consulted on an earlier version of this PEP that was more JIT-specific and they were not interested in utilizing the changes proposed because they want control over memory layout they had no interest in directly supporting -CPython itself. An informal discusion with a developer on the PyPy +CPython itself. An informal discussion with a developer on the PyPy team led to a similar comment. Numba [#numba]_, on the other hand, suggested that they would be diff --git a/pep-0525.txt b/pep-0525.txt index 6ddf418fb09..e8e64179ac8 100644 --- a/pep-0525.txt +++ b/pep-0525.txt @@ -416,7 +416,7 @@ The data flow is defined as follows: unwrapped value as an argument. 2. When ``PyAsyncGenASend.throw(*exc)`` is called for the first time, - ``*exc`` is throwed into the parent ``agen`` object. + ``*exc`` is thrown into the parent ``agen`` object. Subsequent iterations over the ``PyAsyncGenASend`` objects, push ``None`` to ``agen``. diff --git a/pep-0531.txt b/pep-0531.txt index d45ef45bc00..c7eef2e1ae1 100644 --- a/pep-0531.txt +++ b/pep-0531.txt @@ -269,7 +269,7 @@ appropriate operation (e.g. ``math.isnan``, ``cmath.isnan``, Similarly, it seems reasonable to declare that the other placeholder builtin singletons, ``Ellipsis`` and ``NotImplemented``, also qualify as objects that -represent the absence of data moreso than they represent data. +represent the absence of data more so than they represent data. Proposed symbolic notation diff --git a/pep-0554.rst b/pep-0554.rst index 7a924fee67b..8e7b4c66f09 100644 --- a/pep-0554.rst +++ b/pep-0554.rst @@ -844,7 +844,7 @@ API for sharing data Subinterpreters are less useful without a mechanism for sharing data between them. Sharing actual Python objects between interpreters, however, has enough potential problems that we are avoiding support -for that here. Instead, only mimimum set of types will be supported. +for that here. Instead, only minimum set of types will be supported. Initially this will include ``None``, ``bytes``, ``str``, ``int``, and channels. Further types may be supported later. @@ -956,7 +956,7 @@ The module also provides the following channel-related classes:: Channel Lifespan ---------------- -A channel is automatically closed and destoyed once there are no more +A channel is automatically closed and destroyed once there are no more Python objects (e.g. ``RecvChannel`` and ``SendChannel``) referring to it. So it is effectively triggered via garbage-collection of those objects.. @@ -1258,7 +1258,7 @@ this can wait. Pipes and Queues ---------------- -With the proposed object passing machanism of "channels", other similar +With the proposed object passing mechanism of "channels", other similar basic types aren't required to achieve the minimal useful functionality of subinterpreters. Such types include pipes (like unbuffered channels, but one-to-one) and queues (like channels, but more generic). See below diff --git a/pep-0575.rst b/pep-0575.rst index 474d3e9f3d9..407b5131722 100644 --- a/pep-0575.rst +++ b/pep-0575.rst @@ -551,7 +551,7 @@ Some of these are existing (possibly changed) functions, some are new: if the type of ``op`` is ``function``. - ``PyObject *PyFunction_NewPython(PyTypeObject *cls, PyObject *code, PyObject *globals, PyObject *name, PyObject *qualname)``: - create a new instance of ``cls`` (which must be a sublass of ``function``) + create a new instance of ``cls`` (which must be a subclass of ``function``) from the given data. - ``PyObject *PyFunction_New(PyObject *code, PyObject *globals)``: @@ -561,7 +561,7 @@ Some of these are existing (possibly changed) functions, some are new: create a new instance of ``function``. - ``PyObject *PyFunction_Copy(PyTypeObject *cls, PyObject *func)``: - create a new instance of ``cls`` (which must be a sublass of ``function``) + create a new instance of ``cls`` (which must be a subclass of ``function``) by copying a given ``function``. Changes to the types module diff --git a/pep-0587.rst b/pep-0587.rst index e7ae9460cf3..430c8f11a81 100644 --- a/pep-0587.rst +++ b/pep-0587.rst @@ -1332,7 +1332,7 @@ Issues that will be fixed by this PEP, directly or indirectly: callback system for Py_FatalError" * `bpo-11320 `_: "Usage of API method Py_SetPath causes errors in Py_Initialize() - (Posix ony)" + (Posix only)" * `bpo-13533 `_: "Would like Py_Initialize to play friendly with host app" * `bpo-14956 `_: "custom PYTHONPATH diff --git a/pep-0605.rst b/pep-0605.rst index a0369193f38..bd4eb64a751 100644 --- a/pep-0605.rst +++ b/pep-0605.rst @@ -1302,7 +1302,7 @@ In some cases, both usage models may exist within the same organisation for different purposes, such as: * using a stable Python environment for mission critical systems, but allowing - data scientists to use the latest available version for ad hoc data anaylsis + data scientists to use the latest available version for ad hoc data analysis * a hardware manufacturer deploying a stable Python version as part of their production firmware, but using the latest available version in the development and execution of their automated integration tests diff --git a/pep-0610.rst b/pep-0610.rst index 013324aa429..f41e4616c65 100644 --- a/pep-0610.rst +++ b/pep-0610.rst @@ -270,7 +270,7 @@ present as a dictionary with the following key: - ``editable`` (type: ``boolean``): ``true`` if the distribution was installed in editable mode, ``false`` otherwise. If absent, default to ``false``. -When ``url`` refers to a local directory, it MUST have the ``file`` sheme +When ``url`` refers to a local directory, it MUST have the ``file`` scheme and be compliant with `RFC 8089`_. In particular, the path component must be absolute. Symbolic links SHOULD be preserved when making relative paths absolute. diff --git a/pep-0612.rst b/pep-0612.rst index 9df747e4fdc..545f314cf8e 100644 --- a/pep-0612.rst +++ b/pep-0612.rst @@ -435,7 +435,7 @@ afforded to us by this set up: ``Tuple[P.args, ...]`` as would be with a normal annotation (and likewise with the ``**kwargs``\ ) - * This special case is necessary to encapsulate the heterogenous contents + * This special case is necessary to encapsulate the heterogeneous contents of the ``args``/``kwargs`` of a given call, which cannot be expressed by an indefinite tuple/dictionary type. diff --git a/pep-0633.rst b/pep-0633.rst index 581f282952f..8dbcd39649c 100644 --- a/pep-0633.rst +++ b/pep-0633.rst @@ -136,7 +136,7 @@ The keys of the requirement table are as follows (all are optional): of the amendment. - ``revision`` (string): the identifier for a specific revision of the - specified VCS repository to check-out before installtion. Users MUST only + specified VCS repository to check-out before installation. Users MUST only provide this when one of ``git``, ``hg``, ``bzr``, ``svn``, or another VCS key is used to identify the distribution to install. Revision identifiers are suggested in :pep:`610`. diff --git a/pep-0634.rst b/pep-0634.rst index 4b94edd31e9..8067a05c9b0 100644 --- a/pep-0634.rst +++ b/pep-0634.rst @@ -402,7 +402,7 @@ subpatterns succeed in matching their corresponding item, the sequence pattern succeeds. A variable-length sequence pattern first matches the leading non-star -subpatterns to the curresponding items of the subject sequence, as for +subpatterns to the corresponding items of the subject sequence, as for a fixed-length sequence. If this succeeds, the star subpattern matches a list formed of the remaining subject items, with items removed from the end corresponding to the non-star subpatterns diff --git a/pep-0637.rst b/pep-0637.rst index e7ede054162..50cd30d63c2 100644 --- a/pep-0637.rst +++ b/pep-0637.rst @@ -962,7 +962,7 @@ expecting a call like:: type(obj).__setitem__(obj, SENTINEL, 0, **{"value": 1}) -will instead accidentally be catched by the named ``value``, producing a +will instead accidentally be caught by the named ``value``, producing a ``duplicate value error``. The user should not be worried about the actual local names of those two arguments if they are, for all practical purposes, positional only. Unfortunately, using positional-only values will ensure this diff --git a/pep-0642.rst b/pep-0642.rst index 4bd94f24f87..47df5281d34 100644 --- a/pep-0642.rst +++ b/pep-0642.rst @@ -58,7 +58,7 @@ types as follows: * group patterns: ``(PTRN)`` * value constraint patterns: * equality constraints: ``== EXPR`` - * identity contraints: ``is EXPR`` + * identity constraints: ``is EXPR`` * structural constraint patterns: * sequence constraint patterns: ``[PTRN, as NAME, PTRN as NAME]`` * mapping constraint patterns: ``{EXPR: PTRN, EXPR as NAME}`` @@ -239,7 +239,7 @@ restricted to top level patterns and to group patterns (which are patterns surrounded by parentheses). Closed patterns are patterns which either consist of a single token -(i.e. ``__``), or else have a closing delimeter as a required part of their +(i.e. ``__``), or else have a closing delimiter as a required part of their syntax (e.g. ``[as x, as y]``, ``object{.x as x, .y as y}``). As in PEP 634, the ``match`` and ``case`` keywords are soft keywords, i.e. they @@ -1228,7 +1228,7 @@ Changes to sequence patterns This PEP makes one notable change to sequence patterns relative to PEP 634: * only the square bracket form of sequence pattern is supported. Neither open - (no delimeters) nor tuple style (parentheses as delimiters) sequence patterns + (no delimiters) nor tuple style (parentheses as delimiters) sequence patterns are supported. Relative to PEP 634, sequence patterns are also significantly affected by the @@ -1243,7 +1243,7 @@ flexibility that had been included in the original syntax proposal purely for consistency with iterable unpacking. Allowing open and tuple style sequence patterns didn't increase expressivity, -only ambiguity of intent (especially relative to group paterns), and encouraged +only ambiguity of intent (especially relative to group patterns), and encouraged readers down the path of viewing pattern matching syntax as intrinsically linked to assignment target syntax (which the PEP 634 authors have stated multiple times is not a desirable path to have readers take, and a view the author of @@ -1540,7 +1540,7 @@ membership check in Python:: case == 0 | == 1 | == 2 | == 3: ... -Allowing inferred equality contraints under this PEP would only make it look +Allowing inferred equality constraints under this PEP would only make it look like the PEP 634 example, it still wouldn't look like the equivalent ``if`` statement header (``if value in {0, 1, 2, 3}:``). diff --git a/pep-0646.rst b/pep-0646.rst index fcbe74ee04e..a8674685204 100644 --- a/pep-0646.rst +++ b/pep-0646.rst @@ -1142,7 +1142,7 @@ A question we are often asked about this PEP is: why not just use named tensors? The answer is that we consider the named tensors approach insufficient, for two main reasons: * **Static checking** of shape correctness is not possible. As mentioned in `Motivation`_, - this is a highly desireable feature in machine learning code where iteration times + this is a highly desirable feature in machine learning code where iteration times are slow by default. * **Interface documentation** is still not possible with this approach. If a function should *only* be willing to take array arguments that have image-like shapes, this cannot be stipulated diff --git a/pep-0651.rst b/pep-0651.rst index 91fa0d040a0..a48715cdb70 100644 --- a/pep-0651.rst +++ b/pep-0651.rst @@ -148,7 +148,7 @@ PyLeaveRecursiveCall() Backwards Compatibility ======================= -This feature is fully backwards compatibile at the Python level. +This feature is fully backwards compatible at the Python level. Some low-level tools, such as machine-code debuggers, will need to be modified. For example, the gdb scripts for Python will need to be aware that there may be more than one Python frame per C frame. diff --git a/pep-0652.rst b/pep-0652.rst index 324dbfdf76b..ede2de38e93 100644 --- a/pep-0652.rst +++ b/pep-0652.rst @@ -71,7 +71,7 @@ but has major issues: for example, the set exported symbols has platform-specific variations. Also, the cost of updating an explicit manifest is small compared to the overall work that should go into changing API that will need to -be suppported forever (or until Python 3 reaches end of life, if that +be supported forever (or until Python 3 reaches end of life, if that comes sooner). This PEP proposes automatically generating things *from* the manifest: @@ -203,7 +203,7 @@ The format of the manifest will be subject to change whenever needed. It should be consumed only by scripts in the CPython repository. If a stable list is needed, a script can be added to generate it. -The following wil be generated from the ABI manifest: +The following will be generated from the ABI manifest: * Source for the Windows shared library, ``PC/python3dll.c``. * Input for documentation (see below). diff --git a/pep-0653.rst b/pep-0653.rst index 77edfb54f7f..7c97e59103c 100644 --- a/pep-0653.rst +++ b/pep-0653.rst @@ -37,7 +37,7 @@ Precise semantics PEP 634 explicitly includes a section on undefined behavior. Large amounts of undefined behavior may be acceptable in a language like C, but in Python it should be kept to a minimum. -Pattern matching in Python can be defined more precisely without loosing expressiveness or performance. +Pattern matching in Python can be defined more precisely without losing expressiveness or performance. Improved control over class matching ------------------------------------ @@ -508,7 +508,7 @@ Implementations are allowed to make the following assumptions: * Mappings, that is any class for which ``__match_container__ == MATCH_MAPPING`` is not zero, will not capture the second argument of the ``get()`` method. So, the ``$sentinel`` value may be freely re-used. -In fact, implementations are encouraged to make these assumptions, as it is likely to result in signficantly better performance. +In fact, implementations are encouraged to make these assumptions, as it is likely to result in significantly better performance. Security Implications @@ -544,7 +544,7 @@ Sequence patterns This is probably the most complex to optimize and the most profitable in terms of performance. Since each pattern can only match a range of lengths, often only a single length, -the sequence of tests can be rewitten in as an explicit iteration over the sequence, +the sequence of tests can be rewritten in as an explicit iteration over the sequence, attempting to match only those patterns that apply to that sequence length. For example: @@ -642,7 +642,7 @@ The changes to the semantics can be summarized as: This make pattern matching a bit more robust and optimizable as ``__match_args__`` can be assumed to be immutable. * Selecting the kind of container patterns that can be matched uses ``cls.__match_container__`` instead of ``issubclass(cls, collections.abc.Mapping)`` and ``issubclass(cls, collections.abc.Sequence)``. -* Allows classes to opt out of deconstruction altogether, if neccessary, but setting ``__match_class__ = 0``. +* Allows classes to opt out of deconstruction altogether, if necessary, but setting ``__match_class__ = 0``. * The behavior when matching patterns is more precisely defined, but is otherwise unchanged. There are no changes to syntax. All examples given in the PEP 636 tutorial should continue to work as they do now. diff --git a/pep-0654.rst b/pep-0654.rst index 4b449be3b3b..c4c14f0bd5c 100644 --- a/pep-0654.rst +++ b/pep-0654.rst @@ -151,7 +151,7 @@ fields ``message`` and ``exceptions``. For example: The difference between them is that ``ExceptionGroup`` can only wrap ``Exception`` subclasses while ``BaseExceptionGroup`` can wrap any ``BaseException`` subclass. A factory method that inspects the nested -execptions and selects between ``ExceptionGroup`` and ``BaseExceptionGroup`` +exceptions and selects between ``ExceptionGroup`` and ``BaseExceptionGroup`` makes the choice automatic. In the rest of the document, when we refer to an exception group, we mean either an ``ExceptionGroup`` or a ``BaseExceptionGroup``. When it is necessary to make the distunction, we diff --git a/pep-0656.rst b/pep-0656.rst index 25b8543bcc0..06d10c4f5b9 100644 --- a/pep-0656.rst +++ b/pep-0656.rst @@ -15,7 +15,7 @@ Resolution: https://discuss.python.org/t/7165/32 Abstract ======== -This PEP proposes a new platfrom tag series ``musllinux`` for +This PEP proposes a new platform tag series ``musllinux`` for binary Python package distributions for a Python installation that depends on musl on a Linux distribution. The tag works similarly to the "perennial manylinux" platform tags specified in :pep:`600`, but diff --git a/pep-0659.rst b/pep-0659.rst index 003cda68858..74728a69a90 100644 --- a/pep-0659.rst +++ b/pep-0659.rst @@ -44,7 +44,7 @@ Both academic research and practical implementations have shown that a fast inte Typical optimizations for virtual machines are expensive, so a long "warm up" time is required to gain confidence that the cost of optimization is justified. -In order to get speed-ups rapidly, without noticable warmup times, +In order to get speed-ups rapidly, without noticeable warmup times, the VM should speculate that specialization is justified even after a few executions of a function. To do that effectively, the interpreter must be able to optimize and deoptimize continually and very cheaply. @@ -150,7 +150,7 @@ Quickened instructions will be stored in an array (it is neither necessary not d format as the original bytecode. Ancillary data will be stored in a separate array. Each instruction will use 0 or more data entries. Each instruction within a family must have the same amount of data allocated, although some -instructions may not use all of it. Instructions that connot be specialized, e.g. ``POP_TOP``, do not need any entries. +instructions may not use all of it. Instructions that cannot be specialized, e.g. ``POP_TOP``, do not need any entries. Experiments show that 25% to 30% of instructions can be usefully specialized. Different families will need different amounts of data, but most need 2 entries (16 bytes on a 64 bit machine). @@ -172,7 +172,7 @@ CALL_FUNCTION The ``CALL_FUNCTION`` instruction calls the (N+1)th item on the stack with top N items on the stack as arguments. -This is an obvious candidate for specialization. For example, the call in ``len(x)`` is repesented as the bytecode ``CALL_FUNCTION 1``. +This is an obvious candidate for specialization. For example, the call in ``len(x)`` is represented as the bytecode ``CALL_FUNCTION 1``. In this case we would always expect the object ``len`` to be the function. We probably don't want to specialize for ``len`` (although we might for ``type`` and ``isinstance``), but it would be beneficial to specialize for builtin functions taking a single argument. A fast check that the underlying function is a builtin function taking a single argument (``METHOD_O``) would allow us to avoid a diff --git a/pep-0660.rst b/pep-0660.rst index ac899531a81..e18b86631c5 100644 --- a/pep-0660.rst +++ b/pep-0660.rst @@ -43,7 +43,7 @@ Rationale PEP 517 deferred "Editable installs", meaning non-``setup.py`` distributions lacked that feature. The only way to retain ``editable`` installs for these distributions was to provide a compatible ``setup.py develop`` -implementation. By definining an editable hook other build frontends gain +implementation. By defining an editable hook other build frontends gain parity with ``setup.py``. Terminology and goals diff --git a/pep-0662.rst b/pep-0662.rst index f7c490360f2..1567ec77aae 100644 --- a/pep-0662.rst +++ b/pep-0662.rst @@ -263,9 +263,9 @@ Frontend requirements The frontend must install the virtual wheel exactly as defined within :pep:`427`. Furthermore is responsible for also installing the files defined -witin the ``editable.json`` file. The manner in which it does is left up to +within the ``editable.json`` file. The manner in which it does is left up to the frontend, and is encouraged for the frontend to communicate with the user -exactly the method choosen, and what limitations that solution will have. +exactly the method chosen, and what limitations that solution will have. The frontend must create a ``direct_url.json`` file in the ``.dist-info`` directory of the installed distribution, in compliance with PEP 610. The ``url`` diff --git a/pep-0663.txt b/pep-0663.txt index 450084bcfd2..e02b998d419 100644 --- a/pep-0663.txt +++ b/pep-0663.txt @@ -64,7 +64,7 @@ Note that format() already produces the correct output in 3.10, only str() needs updating. As much as possible, the ``str()`, ``repr()``, and ``format()`` of enum members -should be standardized across the stardard library. +should be standardized across the standard library. The repr() of Flag currently includes aliases, which it should not; fixing that will, of course, already change its ``repr()`` in certain cases. @@ -182,7 +182,7 @@ Normal usage of enum members will not change: ``re.ASCII`` can still be used as ``re.ASCII`` and will still compare equal to ``256``. If the previous output needs to be maintained, for example to ensure -compatibily between different Python versions, software projects will need to +compatibility between different Python versions, software projects will need to create their own enum base class with the appropriate methods overridden. Note that by changing the ``str()`` of the drop-in category, we will actually diff --git a/pep-0665.rst b/pep-0665.rst index 576889672ac..2dab47b1655 100644 --- a/pep-0665.rst +++ b/pep-0665.rst @@ -236,7 +236,7 @@ Specifying a single file format can also increase the pace of innovation around installers and the generation of dependency graphs. By decoupling generating the dependency graph details from installation It allows for each area to grow and innovate independently. It also allows -more flexibilty in tool selection on either end of the dependency graph +more flexibility in tool selection on either end of the dependency graph and installation ends of this process. diff --git a/pep-3101.txt b/pep-3101.txt index bef669afe71..41c17516ea4 100644 --- a/pep-3101.txt +++ b/pep-3101.txt @@ -813,13 +813,13 @@ older system. References ========== -.. [1] Python Library Reference - String formating operations +.. [1] Python Library Reference - String formatting operations http://docs.python.org/library/stdtypes.html#string-formatting-operations .. [2] Python Library References - Template strings http://docs.python.org/library/string.html#string.Template -.. [3] [Python-3000] String formating operations in python 3k +.. [3] [Python-3000] String formatting operations in python 3k https://mail.python.org/pipermail/python-3000/2006-April/000285.html .. [4] Composite Formatting - [.Net Framework Developer's Guide] diff --git a/pep-3110.txt b/pep-3110.txt index fe8361cdb3b..c6d7d3ff575 100644 --- a/pep-3110.txt +++ b/pep-3110.txt @@ -94,7 +94,7 @@ to ``NAME`` means that only valid identifiers can be used as ``except`` targets. Note that the grammar above always requires parenthesized tuples as -exception clases. That way, the ambiguous :: +exception classes. That way, the ambiguous :: except A, B: diff --git a/pep-3116.txt b/pep-3116.txt index 62c0d05b59a..1e69c3c582c 100644 --- a/pep-3116.txt +++ b/pep-3116.txt @@ -304,7 +304,7 @@ the cookie returned from ``.tell()``. ``TextIOBase`` implementations also provide several methods that are -pass-throughs to the underlaying ``BufferedIOBase`` objects: +pass-throughs to the underlying ``BufferedIOBase`` objects: ``.flush() -> None`` diff --git a/pep-3132.txt b/pep-3132.txt index 7817f6d45ee..44cf829ca80 100644 --- a/pep-3132.txt +++ b/pep-3132.txt @@ -65,7 +65,7 @@ will be assigned a list of all items from the iterable being unpacked that are not assigned to any of the mandatory expressions, or an empty list if there are no such items. -For example, if ``seq`` is a slicable sequence, all the following +For example, if ``seq`` is a sliceable sequence, all the following assignments are equivalent if ``seq`` has at least two elements:: a, b, c = seq[0], list(seq[1:-1]), seq[-1] diff --git a/pep-3135.txt b/pep-3135.txt index 2477e1b1774..6c93d49f96f 100644 --- a/pep-3135.txt +++ b/pep-3135.txt @@ -139,7 +139,7 @@ The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit -invokation of a super instance upon a class and instance. +invocation of a super instance upon a class and instance. This proposal relies on sys._getframe(), which is not appropriate for anything except a prototype implementation. diff --git a/pep-3141.txt b/pep-3141.txt index 3d0a85d750f..06ec4540301 100644 --- a/pep-3141.txt +++ b/pep-3141.txt @@ -61,7 +61,7 @@ numbers are supported by this hierarchy. :: In short, those are: conversion to complex, bool(), .real, .imag, +, -, *, /, **, abs(), .conjugate(), ==, and !=. - If it is given heterogenous arguments, and doesn't have special + If it is given heterogeneous arguments, and doesn't have special knowledge about them, it should fall back to the builtin complex type as described below. """ diff --git a/pep-3149.txt b/pep-3149.txt index e441d0f637c..53781005333 100644 --- a/pep-3149.txt +++ b/pep-3149.txt @@ -191,13 +191,13 @@ PEP 384 defines a stable ABI for extension modules. In theory, universal adoption of PEP 384 would eliminate the need for this PEP because all extension modules could be compatible with any Python version. In practice of course, it will be impossible to achieve -universal adoption, and as described above, different built-time flags +universal adoption, and as described above, different build-time flags still affect the ABI. Thus even with a stable ABI, this PEP may still be necessary. While a complete specification is reserved for PEP 384, here is a discussion of the relevant issues. PEP 384 describes a change to ``PyModule_Create()`` where ``3`` is -passed as the API version if the extension was complied with +passed as the API version if the extension was compiled with ``Py_LIMITED_API``. This should be formalized into an official macro called ``PYTHON_ABI_VERSION`` to mirror ``PYTHON_API_VERSION``. If and when the ABI changes in an incompatible way, this version number diff --git a/pep-3150.txt b/pep-3150.txt index 5384b67e91a..dfbf449fba5 100644 --- a/pep-3150.txt +++ b/pep-3150.txt @@ -266,7 +266,7 @@ honour of preceding the implementation details: - decorators (which can greatly affect the behaviour of the created object, and were placed ahead of even the keyword and name as a matter - of practicality moreso than aesthetics) + of practicality more so than aesthetics) - the docstring (on the first line immediately following the header line) - parameters, default values and annotations for function definitions - parent classes, metaclass and optionally other details (depending on diff --git a/pep-3156.txt b/pep-3156.txt index c6c81b5a358..19b2b202e7c 100644 --- a/pep-3156.txt +++ b/pep-3156.txt @@ -1778,7 +1778,7 @@ Convenience Utilities --------------------- A few functions and classes are provided to simplify the writing of -basic stream-based clients and servers, such as FTP or HTTP. Thes +basic stream-based clients and servers, such as FTP or HTTP. These are: - ``asyncio.open_connection(host, port)``: A wrapper for diff --git a/pep_sphinx_extensions/pep_theme/static/style.css b/pep_sphinx_extensions/pep_theme/static/style.css index 4172861e39c..29d90b35023 100644 --- a/pep_sphinx_extensions/pep_theme/static/style.css +++ b/pep_sphinx_extensions/pep_theme/static/style.css @@ -10,7 +10,7 @@ white: #888 blockquote left line header breadcrumbs separator - link underline (hovered/focussed) + link underline (hovered/focused) #ccc: scrollbar #ddd From f11fba0ba8a1b0ee05e1d982a01cdac9e317b59c Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Fri, 17 Sep 2021 11:13:02 -0700 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Jelle Zijlstra --- pep-0400.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-0400.txt b/pep-0400.txt index 23fc804db87..e5a9aeffd55 100644 --- a/pep-0400.txt +++ b/pep-0400.txt @@ -192,7 +192,7 @@ file-like objects (same API). codecs.open() was the only way to open a text file in Unicode mode until Python 2.6. Many Python 2 programs uses this function. Removing codecs.open() implies more work to port programs from Python 2 to -Python 3, especially projetcs using the same code base for the two +Python 3, especially projects using the same code base for the two Python versions (without using 2to3 program). codecs.open() is kept for backward compatibility with Python 2.