From b4c828fb40224d91c0b4167cb17babc6307d3527 Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Tue, 22 Oct 2024 12:28:42 +0100 Subject: [PATCH 1/6] Lint: Normalise whitespace --- .../PULL_REQUEST_TEMPLATE/Mark a PEP Final.md | 2 +- .pre-commit-config.yaml | 7 ++ pep_sphinx_extensions/tests/peps/pep-9000.rst | 2 +- peps/pep-0008.rst | 2 +- peps/pep-0703.rst | 6 +- peps/pep-0705.rst | 1 - peps/pep-0706.rst | 2 +- peps/pep-0713.rst | 1 - peps/pep-0719.rst | 2 - peps/pep-0722.rst | 2 +- peps/pep-0724.rst | 1 - peps/pep-0725.rst | 4 +- peps/pep-0727.rst | 10 +- peps/pep-0728.rst | 34 +++---- peps/pep-0732-concentric.drawio.svg | 2 +- peps/pep-0732.rst | 62 ++++++------- peps/pep-0736.rst | 2 +- peps/pep-0744.rst | 40 ++++---- peps/pep-0746.rst | 4 +- peps/pep-0747.rst | 10 +- peps/pep-0749.rst | 4 +- peps/pep-0750.rst | 92 +++++++++---------- peps/pep-0754.rst | 2 +- peps/pep-0756.rst | 1 - peps/pep-0758.rst | 4 +- peps/pep-0760.rst | 3 +- peps/pep-0762.rst | 18 ++-- peps/pep-0777.rst | 2 +- 28 files changed, 161 insertions(+), 161 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE/Mark a PEP Final.md b/.github/PULL_REQUEST_TEMPLATE/Mark a PEP Final.md index cc667804f70..bd37727c7ac 100644 --- a/.github/PULL_REQUEST_TEMPLATE/Mark a PEP Final.md +++ b/.github/PULL_REQUEST_TEMPLATE/Mark a PEP Final.md @@ -9,6 +9,6 @@ If you're unsure about something, just leave it blank and we'll take a look. * [ ] Any substantial changes since the accepted version approved by the SC/PEP delegate * [ ] Pull request title in appropriate format (``PEP 123: Mark Final``) * [ ] ``Status`` changed to ``Final`` (and ``Python-Version`` is correct) -* [ ] Canonical docs/spec linked with a ``canonical-doc`` directive +* [ ] Canonical docs/spec linked with a ``canonical-doc`` directive (or ``canonical-pypa-spec`` for packaging PEPs, or ``canonical-typing-spec`` for typing PEPs) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 6e4826f5801..89ff7ad05a9 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -17,6 +17,13 @@ repos: - id: mixed-line-ending name: "Normalize mixed line endings" args: [--fix=lf] + - id: end-of-file-fixer + name: "Ensure files end with a single newline" + exclude: '^peps/pep-(0[2-6]|3111|3118|3133|3146).*$' + - id: trailing-whitespace + name: "Remove trailing whitespace" + exclude: '^peps/pep-(0[2-6]|3000|3002|31).*$' + - id: file-contents-sorter name: "Sort codespell ignore list" files: '.codespell/ignore-words.txt' diff --git a/pep_sphinx_extensions/tests/peps/pep-9000.rst b/pep_sphinx_extensions/tests/peps/pep-9000.rst index 84a117c17e5..d1a959125aa 100644 --- a/pep_sphinx_extensions/tests/peps/pep-9000.rst +++ b/pep_sphinx_extensions/tests/peps/pep-9000.rst @@ -1,6 +1,6 @@ PEP: 9000 Title: Test with authors with email addresses -Author: Francis Fussyreverend , +Author: Francis Fussyreverend , Javier Soulfulcommodore Created: 20-Apr-2022 Status: Draft diff --git a/peps/pep-0008.rst b/peps/pep-0008.rst index 087370feddf..733b73e4c93 100644 --- a/peps/pep-0008.rst +++ b/peps/pep-0008.rst @@ -820,7 +820,7 @@ complete sentences, with each sentence ending in a period. You should use one or two spaces after a sentence-ending period in multi-sentence comments, except after the final sentence. -Ensure that your comments are clear and easily understandable to other +Ensure that your comments are clear and easily understandable to other speakers of the language you are writing in. Python coders from non-English speaking countries: please write your diff --git a/peps/pep-0703.rst b/peps/pep-0703.rst index 587819766e0..3277ab688ac 100644 --- a/peps/pep-0703.rst +++ b/peps/pep-0703.rst @@ -713,7 +713,7 @@ that wrap those calls. Python objects should not be allocated through other APIs, such as raw calls to C's malloc or the C++ new operator. Additionally, ``PyObject_Malloc`` should be used only for allocating Python objects; it should not be used for allocating buffers, -storages, or other data structures that are not PyObjects. +storages, or other data structures that are not PyObjects. This PEP also imposes restrictions on the pluggable allocator API (``PyMem_SetAllocator``). When compiling without the GIL, allocators @@ -967,7 +967,7 @@ per-object locking -- another thread might modify the list leading to The problematic borrowed reference APIs are supplemented with functions that return "new references" but are otherwise -equivalent: +equivalent: * ``PyList_FetchItem(list, idx)`` for ``PyList_GetItem`` * ``PyDict_FetchItem(dict, key)`` for ``PyDict_GetItem`` @@ -1087,7 +1087,7 @@ and improve single-threaded performance. Although lock acquisition has low overhead compared to most operations, accessing individual elements of lists and dictionaries are fast operations (so the locking overhead is comparatively larger) and frequent (so the -overhead has more impact). +overhead has more impact). This section describes the challenges with implementing dictionary and list accesses without locking followed by a description of this PEP's diff --git a/peps/pep-0705.rst b/peps/pep-0705.rst index 5ba78e3f938..cae156d4127 100644 --- a/peps/pep-0705.rst +++ b/peps/pep-0705.rst @@ -581,4 +581,3 @@ Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0706.rst b/peps/pep-0706.rst index 5585a809b03..984b7555017 100644 --- a/peps/pep-0706.rst +++ b/peps/pep-0706.rst @@ -110,7 +110,7 @@ However, there are some issues with this approach: affect all subsequent operations on the same ``TarFile`` object. This behavior is fine for most uses, but despite that, it would be very surprising if ``TarFile.extractall`` did this by default. -- Calling ``getmembers`` can be expensive and it +- Calling ``getmembers`` can be expensive and it `requires a seekable archive `__. - When verifying members in advance, it may be necessary to track how each member would have changed the filesystem, e.g. how symlinks are being set up. diff --git a/peps/pep-0713.rst b/peps/pep-0713.rst index 65d117b1d2c..9547b497b31 100644 --- a/peps/pep-0713.rst +++ b/peps/pep-0713.rst @@ -204,4 +204,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0719.rst b/peps/pep-0719.rst index 420c04422fe..27f7301b6a2 100644 --- a/peps/pep-0719.rst +++ b/peps/pep-0719.rst @@ -72,5 +72,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - - diff --git a/peps/pep-0722.rst b/peps/pep-0722.rst index 9d421302711..ab252400dcc 100644 --- a/peps/pep-0722.rst +++ b/peps/pep-0722.rst @@ -231,7 +231,7 @@ reference implementation can be included here. from packaging.requirements import Requirement DEPENDENCY_BLOCK_MARKER = r"(?i)^#\s+script\s+dependencies:\s*$" - + def read_dependency_block(filename): # Use the tokenize module to handle any encoding declaration. with tokenize.open(filename) as f: diff --git a/peps/pep-0724.rst b/peps/pep-0724.rst index 89c6695df2b..7ef23850b8b 100644 --- a/peps/pep-0724.rst +++ b/peps/pep-0724.rst @@ -348,4 +348,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0725.rst b/peps/pep-0725.rst index 13fc866d6f7..52aa8d1c2fb 100644 --- a/peps/pep-0725.rst +++ b/peps/pep-0725.rst @@ -104,7 +104,7 @@ Multiple types of external dependencies can be distinguished: Concrete packages are straightforward to understand, and are a concept present in virtually every package management system. Virtual packages are a concept also present in a number of packaging systems -- but not always, and the -details of their implementation varies. +details of their implementation varies. Cross compilation ----------------- @@ -186,7 +186,7 @@ The two types of concrete packages are supported by PURL_ (Package URL), which implements a scheme for identifying packages that is meant to be portable across packaging ecosystems. Its design is:: - scheme:type/namespace/name@version?qualifiers#subpath + scheme:type/namespace/name@version?qualifiers#subpath The ``scheme`` component is a fixed string, ``pkg``, and of the other components only ``type`` and ``name`` are required. As an example, a package diff --git a/peps/pep-0727.rst b/peps/pep-0727.rst index a6663a87bda..8bc9a638e2d 100644 --- a/peps/pep-0727.rst +++ b/peps/pep-0727.rst @@ -346,14 +346,14 @@ For example: .. code:: java /** - * Returns an Image object that can then be painted on the screen. + * Returns an Image object that can then be painted on the screen. * The url argument must specify an absolute {@link URL}. The name - * argument is a specifier that is relative to the url argument. + * argument is a specifier that is relative to the url argument. *

- * This method always returns immediately, whether or not the + * This method always returns immediately, whether or not the * image exists. When this applet attempts to draw the image on - * the screen, the data will be loaded. The graphics primitives - * that draw the image will incrementally paint on the screen. + * the screen, the data will be loaded. The graphics primitives + * that draw the image will incrementally paint on the screen. * * @param url an absolute URL giving the base location of the image * @param name the location of the image, relative to the url argument diff --git a/peps/pep-0728.rst b/peps/pep-0728.rst index e9556ce2c5a..f68542604d5 100644 --- a/peps/pep-0728.rst +++ b/peps/pep-0728.rst @@ -48,7 +48,7 @@ Another possible use case for this is a sound way to class Movie(TypedDict): name: str director: str - + class Book(TypedDict): name: str author: str @@ -194,12 +194,12 @@ to the ``extra_items`` argument. For example:: class Movie(TypedDict, extra_items=bool): name: str - + a: Movie = {"name": "Blade Runner", "novel_adaptation": True} # OK b: Movie = { "name": "Blade Runner", "year": 1982, # Not OK. 'int' is not assignable to 'bool' - } + } Here, ``extra_items=bool`` specifies that items other than ``'name'`` have a value type of ``bool`` and are non-required. @@ -214,12 +214,12 @@ the ``extra_items`` argument:: def f(movie: Movie) -> None: reveal_type(movie["name"]) # Revealed type is 'str' reveal_type(movie["novel_adaptation"]) # Revealed type is 'bool' - + ``extra_items`` is inherited through subclassing:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class Movie(MovieBase): year: int @@ -315,7 +315,7 @@ function parameters still apply:: class Movie(TypedDict, extra_items=int): name: str - + def f(**kwargs: Unpack[Movie]) -> None: ... # Should be equivalent to: @@ -356,7 +356,7 @@ unless it is declared to be ``ReadOnly`` in the superclass:: class Parent(TypedDict, extra_items=int | None): pass - + class Child(Parent, extra_items=int): # Not OK. Like any other TypedDict item, extra_items's type cannot be changed Second, ``extra_items=T`` effectively defines the value type of any unnamed @@ -384,10 +384,10 @@ For example:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class AdaptedMovie(MovieBase): # Not OK. 'bool' is not assignable to 'int | None' adapted_from_novel: bool - + class MovieRequiredYear(MovieBase): # Not OK. Required key 'year' is not known to 'Parent' year: int | None @@ -478,7 +478,7 @@ checks:: class MovieDetails(TypedDict, extra_items=int | None): name: str year: NotRequired[int] - + details: MovieDetails = {"name": "Kill Bill Vol. 1", "year": 2003} movie: Movie = details # Not OK. While 'int' is assignable to 'int | None', # 'int | None' is not assignable to 'int' @@ -502,7 +502,7 @@ possible for an item to have a :term:`narrower ` type than the class Movie(TypedDict, extra_items=ReadOnly[str | int]): name: str - + class MovieDetails(TypedDict, extra_items=int): name: str year: NotRequired[int] @@ -522,19 +522,19 @@ enforced:: class MovieExtraStr(TypedDict, extra_items=str): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} extra_str: MovieExtraStr = {"name": "No Country for Old Men", "description": ""} extra_int = extra_str # Not OK. 'str' is not assignable to extra items type 'int' extra_str = extra_int # Not OK. 'int' is not assignable to extra items type 'str' - + A non-closed TypedDict type implicitly allows non-required extra keys of value type ``ReadOnly[object]``. Applying the assignability rules between this type and a closed TypedDict type is allowed:: class MovieNotClosed(TypedDict): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} not_closed: MovieNotClosed = {"name": "No Country for Old Men"} extra_int = not_closed # Not OK. @@ -636,8 +636,8 @@ For example:: def f(x: IntDict) -> None: v: dict[str, int] = x # OK v.clear() # OK - - not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} + + not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} regular_dict: dict[str, int] = not_required_num_dict # OK f(not_required_num_dict) # OK @@ -652,7 +652,7 @@ because such dict can be a subtype of dict:: class CustomDict(dict[str, int]): pass - + not_a_regular_dict: CustomDict = {"num": 1} int_dict: IntDict = not_a_regular_dict # Not OK diff --git a/peps/pep-0732-concentric.drawio.svg b/peps/pep-0732-concentric.drawio.svg index 02677c5ee5c..cab0340519f 100644 --- a/peps/pep-0732-concentric.drawio.svg +++ b/peps/pep-0732-concentric.drawio.svg @@ -1,4 +1,4 @@ -
3   
3   
2   
2   
1
1
1
1
2
2
3
3
World
includes readers of the documentation
World...
Documentation Working Group
volunteers who contribute to the docs
Documentation Working Group...
Documentation Editoral Board
trusted group
Documentation Editoral Board...Text is not SVG - cannot display \ No newline at end of file +
3   
3   
2   
2   
1
1
1
1
2
2
3
3
World
includes readers of the documentation
World...
Documentation Working Group
volunteers who contribute to the docs
Documentation Working Group...
Documentation Editoral Board
trusted group
Documentation Editoral Board...Text is not SVG - cannot display diff --git a/peps/pep-0732.rst b/peps/pep-0732.rst index dc79b41e98f..b64ae519721 100644 --- a/peps/pep-0732.rst +++ b/peps/pep-0732.rst @@ -22,16 +22,16 @@ This PEP: Motivation ========== -The Steering Council approved the creation of a +The Steering Council approved the creation of a `Documentation Working Group `_ in March 2021 to set direction for the docs. This group is now called the Editorial Board to differentiate it from the Documentation Working Group that was created -since then to focus on more tactical work. +since then to focus on more tactical work. -The purpose of the Python documentation is to serve the -present and future end users of Python. As such, the core -development community and the greater Python documentation +The purpose of the Python documentation is to serve the +present and future end users of Python. As such, the core +development community and the greater Python documentation contributors work together to achieve this: .. image:: pep-0732-concentric.drawio.svg @@ -66,7 +66,7 @@ The editorial board will: Responsibilities ---------------- -The board has authority to make decisions about Python’s +The board has authority to make decisions about Python’s documentation, as scoped below. For example, it can: * Set big-picture strategy for Python’s documentation @@ -94,9 +94,9 @@ The Editorial board oversees the content and strategy for the following: - PEPs (peps.python.org) * - - PyPA documentation - * - + * - - www.python.org - * - + * - - The Python Wiki (wiki.python.org) @@ -127,52 +127,52 @@ Editorial board members should have: * A history of making significant contributions to Python * A willingness to dedicate time to improving Python's docs -Members of the Editorial Board should have experience in education, -communication, technical writing, Python’s documentation, accessibility, +Members of the Editorial Board should have experience in education, +communication, technical writing, Python’s documentation, accessibility, translation, or community management. Term ~~~~ -Editorial Board members serve for an indefinite term, though it is -generally expected that there will be changes in Editorial Board -composition each year. Editorial Board members will confirm annually -whether they wish to continue as a board member. Members may resign +Editorial Board members serve for an indefinite term, though it is +generally expected that there will be changes in Editorial Board +composition each year. Editorial Board members will confirm annually +whether they wish to continue as a board member. Members may resign at any time. -If a board member drops out of touch and cannot be contacted for a +If a board member drops out of touch and cannot be contacted for a month or longer, then the rest of the board may vote to replace them. Changes to the Editorial Board's Size ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Annually after each major Python release, the Editorial Board will -review whether the board's size should change. This provides -flexibility if the needs of the documentation community change -over time. A simple majority is needed to make a decision to +Annually after each major Python release, the Editorial Board will +review whether the board's size should change. This provides +flexibility if the needs of the documentation community change +over time. A simple majority is needed to make a decision to increase the board's size where quorum is 80% of the current board. -As the sponsoring organization of the Documentation Editorial -Board, the Steering Council may change the number of members of -the Board at any time, including appointing new members or -dismissing existing members. +As the sponsoring organization of the Documentation Editorial +Board, the Steering Council may change the number of members of +the Board at any time, including appointing new members or +dismissing existing members. Vacancies ~~~~~~~~~ -If a vacancy exists on the board for any reason, the Documentation -Editorial Board will publicly announce a call for prospective -board members. Prospective board members would submit a brief -document stating qualifications and their motivation to serve. -The sitting members of the Editorial Board will select new board +If a vacancy exists on the board for any reason, the Documentation +Editorial Board will publicly announce a call for prospective +board members. Prospective board members would submit a brief +document stating qualifications and their motivation to serve. +The sitting members of the Editorial Board will select new board members by a simple majority where quorum is 80% of the current board. Amendments ========== -This PEP serves as a charter for the Docs Editorial Board. Changes -to its operation can be made either through a new PEP or through -a change to this PEP. In either case, the change would be decided +This PEP serves as a charter for the Docs Editorial Board. Changes +to its operation can be made either through a new PEP or through +a change to this PEP. In either case, the change would be decided upon by the Steering Council after discussion in the community. diff --git a/peps/pep-0736.rst b/peps/pep-0736.rst index 64b7acc04f2..67656390443 100644 --- a/peps/pep-0736.rst +++ b/peps/pep-0736.rst @@ -424,7 +424,7 @@ Recommendations for using this syntax As with any other language feature, the programmer should exercise their own judgement about whether it is prudent to use it in any given context. We do not -recommend enforcing a rule to use the feature in all cases where it may be +recommend enforcing a rule to use the feature in all cases where it may be applicable. As described `above `__, we propose that a diff --git a/peps/pep-0744.rst b/peps/pep-0744.rst index 9a0ff3de2e8..1f9ef1ef84d 100644 --- a/peps/pep-0744.rst +++ b/peps/pep-0744.rst @@ -99,10 +99,10 @@ physical hardware registers). Since much of this data varies even between identical runs of a program and the existing optimization pipeline makes heavy use of runtime profiling information, -it doesn't make much sense to compile these traces ahead of time and would be a -substantial redesign of the existing specification and micro-op tracing infrastructure -that has already been implemented. As has been demonstrated for many other dynamic -languages (`and even Python itself `__), the most promising +it doesn't make much sense to compile these traces ahead of time and would be a +substantial redesign of the existing specification and micro-op tracing infrastructure +that has already been implemented. As has been demonstrated for many other dynamic +languages (`and even Python itself `__), the most promising approach is to compile the optimized micro-ops "just in time" for execution. Rationale @@ -120,7 +120,7 @@ high-quality Python-specific optimizations for the code being run, *but also* quick generation of efficient machine code for the optimized program. The Python core development team has the necessary skills and experience for the former (a middle-end tightly coupled to the interpreter), and copy-and-patch compilation -provides an attractive solution for the latter. +provides an attractive solution for the latter. In a nutshell, copy-and-patch allows a high-quality template JIT compiler to be generated from the same DSL used to generate the rest of the interpreter. For a @@ -139,9 +139,9 @@ code and 500 lines of runtime C code. Specification ============= -The JIT is currently not part of the default build configuration, and it is -likely to remain that way for the foreseeable future (though official binaries -may include it). That said, the JIT will become non-experimental once all of +The JIT is currently not part of the default build configuration, and it is +likely to remain that way for the foreseeable future (though official binaries +may include it). That said, the JIT will become non-experimental once all of the following conditions are met: #. It provides a meaningful performance improvement for at least one popular @@ -245,7 +245,7 @@ Since the code templates emitted by the JIT are compiled by Clang, it *may* be possible to allow JIT frames to be traced through by simply modifying the compiler flags to use frame pointers more carefully. It may also be possible to harvest and emit the debugging information produced by Clang. Neither of these -ideas have been explored very deeply. +ideas have been explored very deeply. While this is an issue that *should* be fixed, fixing it is not a particularly high priority at this time. This is probably a problem best explored by somebody @@ -299,7 +299,7 @@ How to Teach This Choose the sections that best describe you: - **If you are a Python programmer or end user...** - + - ...nothing changes for you. Nobody should be distributing JIT-enabled CPython interpreters to you while it is still an experimental feature. Once it is non-experimental, you will probably notice slightly better performance @@ -317,7 +317,7 @@ Choose the sections that best describe you: - ...nothing changes for you. All Python profiling and tracing functionality remains. - + - **If you profile or debug C code...** - ...currently, the ability to trace *through* JIT frames is limited. This may @@ -376,13 +376,13 @@ Reference Implementation Key parts of the implementation include: - |readme|_: Instructions for how to build the JIT. - + - |jit|_: The entire runtime portion of the JIT compiler. - + - |jit_stencils|_: An example of the JIT's generated templates. - + - |template|_: The code which is compiled to produce the JIT's templates. - + - |targets|_: The code to compile and parse the templates at build time. .. |readme| replace:: ``Tools/jit/README.md`` @@ -500,7 +500,7 @@ Open Issues Speed ----- -Currently, the JIT is `about as fast as the existing specializing interpreter +Currently, the JIT is `about as fast as the existing specializing interpreter `__ on most platforms. Improving this is obviously a top priority at this point, since providing a significant performance gain is the entire motivation for @@ -528,9 +528,9 @@ likely to be a real concern. Not much effort has been put into optimizing the JIT's memory usage yet, so these numbers likely represent a maximum that will be reduced over time. Improving this is a medium priority, and is being tracked in `GH-116017 -`__. We may consider +`__. We may consider exposing configurable parameters for limiting memory consumption in the -future, but no official APIs will be exposed until the JIT meets the +future, but no official APIs will be exposed until the JIT meets the requirements to be considered non-experimental. Earlier versions of the JIT had a more complicated memory allocation scheme @@ -543,8 +543,8 @@ Dependencies At the time of writing, the JIT has a build-time dependency on LLVM. LLVM is used to compile individual micro-op instructions into blobs of machine code, -which are then linked together to form the JIT's templates. These templates are -used to build CPython itself. The JIT has no runtime dependency on LLVM and is +which are then linked together to form the JIT's templates. These templates are +used to build CPython itself. The JIT has no runtime dependency on LLVM and is therefore not at all exposed as a dependency to end users. Building the JIT adds between 3 and 60 seconds to the build process, depending diff --git a/peps/pep-0746.rst b/peps/pep-0746.rst index 342b730aa69..f4665f83ea1 100644 --- a/peps/pep-0746.rst +++ b/peps/pep-0746.rst @@ -54,7 +54,7 @@ that specifies whether the metadata is valid for a given type:: __supports_annotated_base__: int The attribute may also be marked as a ``ClassVar`` to avoid interaction with dataclasses:: - + from dataclasses import dataclass from typing import ClassVar @@ -77,7 +77,7 @@ To support generic ``Gt`` metadata, one might write:: class SupportsGt[T](Protocol): def __gt__(self, __other: T) -> bool: ... - + class Gt[T]: __supports_annotated_base__: ClassVar[SupportsGt[T]] diff --git a/peps/pep-0747.rst b/peps/pep-0747.rst index 1d5483ad77d..b91078673f3 100644 --- a/peps/pep-0747.rst +++ b/peps/pep-0747.rst @@ -284,7 +284,7 @@ intent to use the value as a type form object. Second, static type checkers validate that all rules for type expressions are followed:: x4 = type(int) # No error, evaluates to "type[int]" - + x5 = TypeForm(type(int)) # Error: call not allowed in type expression @@ -341,7 +341,7 @@ by a function parameter, returned by a function, or stored in a variable: ^ | variable type - + return sum Type expressions evaluate to valid *type form* objects at runtime and can be @@ -353,8 +353,8 @@ assigned to variables and manipulated like any other data in a program: | | v v int_type_form: TypeForm = int | None - ^ - | + ^ + | the type of a type form object ``TypeForm[]`` is how you spell the type of a *type form* object, which is @@ -381,7 +381,7 @@ type form object as input. :: from trycast import isassignable - + if isassignable(some_object, MyTypedDict): # OK: MyTypedDict is a TypeForm[] ... diff --git a/peps/pep-0749.rst b/peps/pep-0749.rst index 5afd763a2d2..303ee18dd1d 100644 --- a/peps/pep-0749.rst +++ b/peps/pep-0749.rst @@ -64,7 +64,7 @@ The future of ``from __future__ import annotations`` which changes all annotations to strings. :pep:`649` proposes an alternative approach that does not require this future import, and states: - If this PEP is accepted, PEP 563 will be deprecated and eventually removed. + If this PEP is accepted, PEP 563 will be deprecated and eventually removed. However, the PEP does not provide a detailed plan for this deprecation. @@ -922,7 +922,7 @@ code execution even with no access to any globals or builtins. For example: .. code-block:: pycon >>> def f(x: (1).__class__.__base__.__subclasses__()[-1].__init__.__builtins__["print"]("Hello world")): pass - ... + ... >>> annotationlib.get_annotations(f, format=annotationlib.Format.SOURCE) Hello world {'x': 'None'} diff --git a/peps/pep-0750.rst b/peps/pep-0750.rst index 3291da787ea..5009d97a47a 100644 --- a/peps/pep-0750.rst +++ b/peps/pep-0750.rst @@ -57,7 +57,7 @@ Motivation ========== Python f-strings are easy to use and very popular. Over time, however, developers -have encountered limitations that make them +have encountered limitations that make them `unsuitable for certain use cases `__. In particular, f-strings provide no way to intercept and transform interpolated values before they are combined into a final string. @@ -108,7 +108,7 @@ Template String Literals ------------------------ This PEP introduces a new string prefix, ``t``, to define template string literals. -These literals resolve to a new type, ``Template``, found in a new top-level +These literals resolve to a new type, ``Template``, found in a new top-level standard library module, ``templatelib``. The following code creates a ``Template`` instance: @@ -139,7 +139,7 @@ Template strings evaluate to an instance of a new type, ``templatelib.Template`` class Template: args: Sequence[str | Interpolation] - + def __init__(self, *args: str | Interpolation): ... @@ -187,7 +187,7 @@ Like ``Template``, it is a new concrete type found in the ``templatelib`` module ): ... -Like ``Template``, ``Interpolation`` is shallow immutable. Its attributes +Like ``Template``, ``Interpolation`` is shallow immutable. Its attributes cannot be reassigned. The ``value`` attribute is the evaluated result of the interpolation: @@ -292,8 +292,8 @@ for detailed working examples. Template String Concatenation ----------------------------- -Template strings support explicit concatenation using ``+``. Concatenation is -supported for two ``Template`` instances as well as for a ``Template`` instance +Template strings support explicit concatenation using ``+``. Concatenation is +supported for two ``Template`` instances as well as for a ``Template`` instance and a ``str``: .. code-block:: python @@ -305,10 +305,10 @@ and a ``str``: assert template1 + "!" == t"Hello !" assert "Hello " + template2 == t"Hello {name}" -Concatenation of templates is "viral": the concatenation of a ``Template`` and +Concatenation of templates is "viral": the concatenation of a ``Template`` and a ``str`` always results in a ``Template`` instance. -Python's implicit concatenation syntax is also supported. The following code +Python's implicit concatenation syntax is also supported. The following code will work as expected: .. code-block:: python @@ -320,7 +320,7 @@ will work as expected: assert template2 == t"Hello World" -The ``Template`` type implements the ``__add__()`` and ``__radd__()`` methods +The ``Template`` type implements the ``__add__()`` and ``__radd__()`` methods roughly as follows: .. code-block:: python @@ -339,7 +339,7 @@ roughly as follows: return Template(other + self.args[0], *self.args[1:]) Special care is taken to ensure that the interleaving of ``str`` and ``Interpolation`` -instances is maintained when concatenating. (See the +instances is maintained when concatenating. (See the `Interleaving of Template.args`_ section for more information.) @@ -386,7 +386,7 @@ No Support for Ordering ----------------------- The ``Template`` and ``Interpolation`` types do not support ordering. This is -unlike all other string literal types in Python, which support lexicographic +unlike all other string literal types in Python, which support lexicographic ordering. Because interpolations can contain arbitrary values, there is no natural ordering for them. As a result, neither the ``Template`` nor the ``Interpolation`` type implements the standard comparison methods. @@ -501,8 +501,8 @@ evaluated with different values. Access to the static parts can be done with Interleaving is an invariant maintained by the ``Template`` class. Developers can take advantage of it but they are not required to themselves maintain it. -Specifically, ``Template.__init__()`` can be called with ``str`` and -``Interpolation`` instances in *any* order; the constructor will "interleave" them +Specifically, ``Template.__init__()`` can be called with ``str`` and +``Interpolation`` instances in *any* order; the constructor will "interleave" them as necessary before assigning them to ``args``. @@ -736,7 +736,7 @@ logging: .. note:: Example code See `logging.py`__ and `test_logging.py`__. - + __ https://github.com/davepeck/pep750-examples/blob/main/pep/logging.py __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_logging.py @@ -748,7 +748,7 @@ This PEP contains several short HTML templating examples. It turns out that the "hypothetical" ``html()`` function mentioned in the `Motivation`_ section (and a few other places in this PEP) exists and is available in the `pep750-examples repository `_. -If you're thinking about parsing a complex grammar with template strings, we +If you're thinking about parsing a complex grammar with template strings, we hope you'll find it useful. @@ -786,26 +786,26 @@ We hope that teaching developers will be straightforward. At a glance, template strings look just like f-strings. Their syntax is familiar and the scoping rules remain the same. -The first thing developers must learn is that template string literals don't -evaluate to strings; instead, they evaluate to a new type, ``Template``. This +The first thing developers must learn is that template string literals don't +evaluate to strings; instead, they evaluate to a new type, ``Template``. This is a simple type intended to be used by template processing code. It's not until -developers call a processing function that they get the result they want: -typically, a string, although processing code can of course return any arbitrary +developers call a processing function that they get the result they want: +typically, a string, although processing code can of course return any arbitrary type. -Because developers will learn that t-strings are nearly always used in tandem -with processing functions, they don't necessarily need to understand the details +Because developers will learn that t-strings are nearly always used in tandem +with processing functions, they don't necessarily need to understand the details of the ``Template`` type. As with descriptors and decorators, we expect many more developers will use t-strings than write t-string processing functions. -Over time, a small number of more advanced developers *will* wish to author their -own template processing code. Writing processing code often requires thinking -in terms of formal grammars. Developers will need to learn how to parse the -``args`` attribute of a ``Template`` instance and how to process interpolations -in a context-sensitive fashion. More sophisticated grammars will likely require -parsing to intermediate representations like an AST. Great template processing -code will handle format specifiers and conversions when appropriate. Writing -production-grade template processing code -- for instance, to support HTML +Over time, a small number of more advanced developers *will* wish to author their +own template processing code. Writing processing code often requires thinking +in terms of formal grammars. Developers will need to learn how to parse the +``args`` attribute of a ``Template`` instance and how to process interpolations +in a context-sensitive fashion. More sophisticated grammars will likely require +parsing to intermediate representations like an AST. Great template processing +code will handle format specifiers and conversions when appropriate. Writing +production-grade template processing code -- for instance, to support HTML templates -- can be a large undertaking. We expect that template strings will provide framework authors with a powerful @@ -1016,7 +1016,7 @@ and is able to ``await`` an interpolation's value. .. note:: Example code See `aformat.py`__ and `test_aformat.py`__. - + __ https://github.com/davepeck/pep750-examples/blob/main/pep/aformat.py __ https://github.com/davepeck/pep750-examples/blob/main/pep/test_aformat.py @@ -1186,14 +1186,14 @@ Disallowing String Concatenation Earlier versions of this PEP proposed that template strings should not support concatenation. This was rejected in favor of allowing concatenation. -There are reasonable arguments in favor of rejecting one or all forms of -concatenation: namely, that it cuts off a class of potential bugs, particularly -when one takes the view that template strings will often contain complex grammars -for which concatenation doesn't always have the same meaning (or any meaning). +There are reasonable arguments in favor of rejecting one or all forms of +concatenation: namely, that it cuts off a class of potential bugs, particularly +when one takes the view that template strings will often contain complex grammars +for which concatenation doesn't always have the same meaning (or any meaning). -Moreover, the earliest versions of this PEP proposed a syntax closer to -JavaScript's tagged template literals, where an arbitrary callable could be used -as a prefix to a string literal. There was no guarantee that the callable would +Moreover, the earliest versions of this PEP proposed a syntax closer to +JavaScript's tagged template literals, where an arbitrary callable could be used +as a prefix to a string literal. There was no guarantee that the callable would return a type that supported concatenation. In the end, we decided that the surprise to developers of a new string type @@ -1203,7 +1203,7 @@ after all, and while we are sure there are cases where this introduces bugs, it's not clear that those bugs outweigh the benefits of supporting concatenation.) While concatenation is supported, we expect that code that uses template strings -will more commonly build up larger templates through nesting and composition +will more commonly build up larger templates through nesting and composition rather than concatenation. @@ -1221,16 +1221,16 @@ separate PEP. Removing ``conv`` From ``Interpolation`` ---------------------------------------- -During the authoring of this PEP, we considered removing the ``conv`` attribute +During the authoring of this PEP, we considered removing the ``conv`` attribute from ``Interpolation`` and specifying that the conversion should be performed eagerly, before ``Interpolation.value`` is set. This was done to simplify the work of writing template processing code. The ``conv`` attribute is of limited extensibility (it is typed as -``Literal["r", "s", "a"] | None``). It is not clear that it adds significant +``Literal["r", "s", "a"] | None``). It is not clear that it adds significant value or flexibility to template strings that couldn't better be achieved with custom format specifiers. Unlike with format specifiers, there is no -equivalent to Python's :func:`python:format` built-in. (Instead, we include an +equivalent to Python's :func:`python:format` built-in. (Instead, we include an sample implementation of ``convert()`` in the `Examples`_ section.) Ultimately we decided to keep the ``conv`` attribute in the ``Interpolation`` type @@ -1267,11 +1267,11 @@ Alternate Layouts for ``Template.args`` During the development of this PEP, we considered several alternate layouts for the ``args`` attribute of the ``Template`` type. This included: -- Instead of ``args``, ``Template`` contains a ``strings`` attribute of type - ``Sequence[str]`` and an ``interpolations`` attribute of type - ``Sequence[Interpolation]``. There are zero or more interpolations and - there is always one more string than there are interpolations. Utility code - could build an interleaved sequence of strings and interpolations from these +- Instead of ``args``, ``Template`` contains a ``strings`` attribute of type + ``Sequence[str]`` and an ``interpolations`` attribute of type + ``Sequence[Interpolation]``. There are zero or more interpolations and + there is always one more string than there are interpolations. Utility code + could build an interleaved sequence of strings and interpolations from these separate attributes. This was rejected as being overly complex. - ``args`` is typed as a ``Sequence[tuple[str, Interpolation | None]]``. Each diff --git a/peps/pep-0754.rst b/peps/pep-0754.rst index d10565fc52d..94bab4fc0fd 100644 --- a/peps/pep-0754.rst +++ b/peps/pep-0754.rst @@ -209,7 +209,7 @@ Copyright This document has been placed in the public domain. - + .. Local Variables: mode: indented-text diff --git a/peps/pep-0756.rst b/peps/pep-0756.rst index fd5447e860e..c52c9283d37 100644 --- a/peps/pep-0756.rst +++ b/peps/pep-0756.rst @@ -403,4 +403,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0758.rst b/peps/pep-0758.rst index 9a9369117b7..9f7dc270005 100644 --- a/peps/pep-0758.rst +++ b/peps/pep-0758.rst @@ -102,8 +102,8 @@ list of exception types. The grammar will be updated as follows: | 'except' ':' block except_star_block - | 'except' '*' expressions ':' block - | 'except' '*' expression 'as' NAME ':' block + | 'except' '*' expressions ':' block + | 'except' '*' expression 'as' NAME ':' block This allows both the current parenthesized syntax and the new unparenthesized syntax while requiring parentheses when the ``as`` keyword is used: diff --git a/peps/pep-0760.rst b/peps/pep-0760.rst index 888f2b373b4..721944c3d03 100644 --- a/peps/pep-0760.rst +++ b/peps/pep-0760.rst @@ -180,7 +180,7 @@ Rejected ideas This code guarantees that no matter what exception occurs, any open transaction will be aborted, while in the successful condition, the - transaction will be committed. + transaction will be committed. We do believe that although there are cases such like this one where bare ``except:`` handlers are correct, it would be better to actually @@ -202,4 +202,3 @@ CC0-1.0-Universal license, whichever is more permissive. .. [6] https://4.docs.plone.org/develop/plone-coredev/style.html#concrete-rules .. [7] https://docs.openedx.org/en/latest/developers/references/developer_guide/style_guides/python-guidelines.html .. [8] https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/database/transaction.py#L27 - diff --git a/peps/pep-0762.rst b/peps/pep-0762.rst index c3dc8295ffd..a4d1aa77d2b 100644 --- a/peps/pep-0762.rst +++ b/peps/pep-0762.rst @@ -1,7 +1,7 @@ PEP: 762 Title: REPL-acing the default REPL Author: Pablo Galindo Salgado , Łukasz Langa , Lysandros Nikolaou , Emily Morehouse-Valcarcel -Sponsor: Pablo Galindo Salgado +Sponsor: Pablo Galindo Salgado Status: Final Type: Informational Created: 11-Oct-2024 @@ -126,19 +126,19 @@ introduces the following key features: 2. Copying and Pasting: in supported terminal emulators, bracketed pasting capability is discovered and used by PyREPL. This allows for transparent pasting of blocks of code without immediate execution or invalid automatic indentation. - + For terminal emulators that don’t support this mode, a dedicated paste mode is implemented to allow for easy insertion of multi-line code snippets without triggering immediate execution or indentation issues. - + Users enter manual paste mode by hitting the :kbd:`F3` key. The prompt changes from ``>>>`` to ``(paste)`` where users can paste contents from their clipboard or manually type as desired. Once the content is ready, hitting :kbd:`F3` exits paste mode. Then, pressing Enter executes the block. - + Users can enter multiple commands on a single input when using paste mode, which will help paste code from other sources. - + To copy blocks of code without the leading command prompts and without the output of the commands, users can enter the history view via the :kbd:`F2` key. This mode uses a pager to display history of executed commands without the prompts @@ -149,13 +149,13 @@ introduces the following key features: Access to the standard Help module is accessible via a Custom Command ``help`` (see below) or via the :kbd:`F1` key. Hit :kbd:`F1` to enter help mode. When you're done, hit :kbd:`F1` or a standard command (``q``, ``quit`` or ``exit``) to exit. - + Browsing interactive help does not retain command history. 4. Custom Commands: The REPL supports the implementation of custom commands, such as ``exit``, in a more natural and user-friendly manner, avoiding the current function call workaround. - + The initial list of custom commands includes: * ``exit`` @@ -163,7 +163,7 @@ introduces the following key features: * ``copyright`` * ``help`` * ``clear`` - + Commands are available as long as there is no name conflict with a variable in a reachable scope. For example, after assigning ``exit = 1``, the variable will take precedence over PyREPL commands. ``del exit`` in this case will remove the @@ -268,7 +268,7 @@ Several alternative approaches were considered and ultimately rejected: and lack of additional dependencies. Another key factor was the alignment with PyPy's implementation. - + Acknowledgments =============== diff --git a/peps/pep-0777.rst b/peps/pep-0777.rst index fb5a9576219..04d99a020f7 100644 --- a/peps/pep-0777.rst +++ b/peps/pep-0777.rst @@ -15,7 +15,7 @@ Abstract The current :pep:`wheel 1.0 specification <427>` was written over a decade ago, and has been extremely robust to changes in the Python packaging ecosystem. -Previous efforts to improve the wheel specification +Previous efforts to improve the wheel specification :pep:`were deferred <491#pep-deferral>` to focus on other packaging specifications. Meanwhile, the use of wheels has changed dramatically in the last decade. There have been many requests for new wheel features over the From c7f8e47de042ce63ca77ee14ab27ae4b53da4493 Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Tue, 22 Oct 2024 15:22:48 +0100 Subject: [PATCH 2/6] Be more explicit in the exclude pattern --- .pre-commit-config.yaml | 22 +++++++++++-- peps/pep-0418/bench_time.c | 1 - peps/pep-0418/clock_resolution.py | 1 - peps/pep-0426/pepsort.py | 1 - peps/pep-0446.rst | 2 -- peps/pep-0446/test_cloexec.py | 1 - peps/pep-0495-gap.svg | 2 +- peps/pep-0532/circuit-breaking-protocol.svg | 2 +- peps/pep-0703.rst | 6 ++-- peps/pep-0705.rst | 1 + peps/pep-0706.rst | 2 +- peps/pep-0713.rst | 1 + peps/pep-0722.rst | 2 +- peps/pep-0724.rst | 1 + peps/pep-0725.rst | 4 +-- peps/pep-0727.rst | 10 +++--- peps/pep-0728.rst | 34 ++++++++++----------- peps/pep-0754.rst | 2 +- 18 files changed, 55 insertions(+), 40 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 89ff7ad05a9..28d976b3dc2 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -19,10 +19,28 @@ repos: args: [--fix=lf] - id: end-of-file-fixer name: "Ensure files end with a single newline" - exclude: '^peps/pep-(0[2-6]|3111|3118|3133|3146).*$' + exclude: | + (?x)^peps/pep-( + 02(30|47|65|72) + |03(42|74) + |04(0[0459]|1[06]|45|51|68) + |0524 + |06(51|72|93|99) + |07(05|13|24) + |31(11|18|33|46) + ).*\.rst$ - id: trailing-whitespace name: "Remove trailing whitespace" - exclude: '^peps/pep-(0[2-6]|3000|3002|31).*$' + args: [--chars, " \t"] + exclude: | + (?x)^peps/pep-( + 0282 + |0484 + |05(17|44|63|82|86) + |061[1567]|062[56]|063[679]|064[356]|065[237]|066[029]|0679|0681|069[1245] + |07(03|06|22|25|27|28) + |3104 + ).*\.rst$ - id: file-contents-sorter name: "Sort codespell ignore list" diff --git a/peps/pep-0418/bench_time.c b/peps/pep-0418/bench_time.c index b426b3e3c4a..ef96de043af 100644 --- a/peps/pep-0418/bench_time.c +++ b/peps/pep-0418/bench_time.c @@ -185,4 +185,3 @@ int main() benchmark("time()", bench_time, 0); return 0; } - diff --git a/peps/pep-0418/clock_resolution.py b/peps/pep-0418/clock_resolution.py index 17993cd8603..3205552ec80 100644 --- a/peps/pep-0418/clock_resolution.py +++ b/peps/pep-0418/clock_resolution.py @@ -69,4 +69,3 @@ def gettime(): test_clock(name, gettime) resolution = time.clock_getres(clock_id) print("- announced resolution: %s" % format_duration(resolution)) - diff --git a/peps/pep-0426/pepsort.py b/peps/pep-0426/pepsort.py index 84e28e37051..ff306ebc57e 100755 --- a/peps/pep-0426/pepsort.py +++ b/peps/pep-0426/pepsort.py @@ -267,4 +267,3 @@ def main(pepno = '426'): filemode='w', format='%(message)s') logger.setLevel(logging.DEBUG) main(pepno) - diff --git a/peps/pep-0446.rst b/peps/pep-0446.rst index 9fd2b05fba9..312cb15a4a5 100644 --- a/peps/pep-0446.rst +++ b/peps/pep-0446.rst @@ -618,5 +618,3 @@ Copyright ========= This document has been placed into the public domain. - - diff --git a/peps/pep-0446/test_cloexec.py b/peps/pep-0446/test_cloexec.py index 88f5a0bd1a0..8f653c5c55f 100644 --- a/peps/pep-0446/test_cloexec.py +++ b/peps/pep-0446/test_cloexec.py @@ -47,4 +47,3 @@ def after_exec(): main() else: after_exec() - diff --git a/peps/pep-0495-gap.svg b/peps/pep-0495-gap.svg index 090213a307a..f31f0517740 100644 --- a/peps/pep-0495-gap.svg +++ b/peps/pep-0495-gap.svg @@ -1 +1 @@ - \ No newline at end of file + diff --git a/peps/pep-0532/circuit-breaking-protocol.svg b/peps/pep-0532/circuit-breaking-protocol.svg index 39086bb0328..ca64f5de118 100644 --- a/peps/pep-0532/circuit-breaking-protocol.svg +++ b/peps/pep-0532/circuit-breaking-protocol.svg @@ -1,2 +1,2 @@ -
x if breaker else y
x <b>if</b> breaker <b>else</b> y<br>
True
True
False
False
bool(breaker)
bool(breaker)
breaker.__then__(x)
breaker.__then__(x)
breaker.__else__(y)
breaker.__else__(y)
When "x is breaker",
this is a short-circuited

"breaker else z"
[Not supported by viewer]
When "y is breaker",
this is a short-circuited

"x if breaker"
[Not supported by viewer] \ No newline at end of file +
x if breaker else y
x <b>if</b> breaker <b>else</b> y<br>
True
True
False
False
bool(breaker)
bool(breaker)
breaker.__then__(x)
breaker.__then__(x)
breaker.__else__(y)
breaker.__else__(y)
When "x is breaker",
this is a short-circuited

"breaker else z"
[Not supported by viewer]
When "y is breaker",
this is a short-circuited

"x if breaker"
[Not supported by viewer] diff --git a/peps/pep-0703.rst b/peps/pep-0703.rst index 3277ab688ac..587819766e0 100644 --- a/peps/pep-0703.rst +++ b/peps/pep-0703.rst @@ -713,7 +713,7 @@ that wrap those calls. Python objects should not be allocated through other APIs, such as raw calls to C's malloc or the C++ new operator. Additionally, ``PyObject_Malloc`` should be used only for allocating Python objects; it should not be used for allocating buffers, -storages, or other data structures that are not PyObjects. +storages, or other data structures that are not PyObjects. This PEP also imposes restrictions on the pluggable allocator API (``PyMem_SetAllocator``). When compiling without the GIL, allocators @@ -967,7 +967,7 @@ per-object locking -- another thread might modify the list leading to The problematic borrowed reference APIs are supplemented with functions that return "new references" but are otherwise -equivalent: +equivalent: * ``PyList_FetchItem(list, idx)`` for ``PyList_GetItem`` * ``PyDict_FetchItem(dict, key)`` for ``PyDict_GetItem`` @@ -1087,7 +1087,7 @@ and improve single-threaded performance. Although lock acquisition has low overhead compared to most operations, accessing individual elements of lists and dictionaries are fast operations (so the locking overhead is comparatively larger) and frequent (so the -overhead has more impact). +overhead has more impact). This section describes the challenges with implementing dictionary and list accesses without locking followed by a description of this PEP's diff --git a/peps/pep-0705.rst b/peps/pep-0705.rst index cae156d4127..5ba78e3f938 100644 --- a/peps/pep-0705.rst +++ b/peps/pep-0705.rst @@ -581,3 +581,4 @@ Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. + diff --git a/peps/pep-0706.rst b/peps/pep-0706.rst index 984b7555017..5585a809b03 100644 --- a/peps/pep-0706.rst +++ b/peps/pep-0706.rst @@ -110,7 +110,7 @@ However, there are some issues with this approach: affect all subsequent operations on the same ``TarFile`` object. This behavior is fine for most uses, but despite that, it would be very surprising if ``TarFile.extractall`` did this by default. -- Calling ``getmembers`` can be expensive and it +- Calling ``getmembers`` can be expensive and it `requires a seekable archive `__. - When verifying members in advance, it may be necessary to track how each member would have changed the filesystem, e.g. how symlinks are being set up. diff --git a/peps/pep-0713.rst b/peps/pep-0713.rst index 9547b497b31..65d117b1d2c 100644 --- a/peps/pep-0713.rst +++ b/peps/pep-0713.rst @@ -204,3 +204,4 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. + diff --git a/peps/pep-0722.rst b/peps/pep-0722.rst index ab252400dcc..9d421302711 100644 --- a/peps/pep-0722.rst +++ b/peps/pep-0722.rst @@ -231,7 +231,7 @@ reference implementation can be included here. from packaging.requirements import Requirement DEPENDENCY_BLOCK_MARKER = r"(?i)^#\s+script\s+dependencies:\s*$" - + def read_dependency_block(filename): # Use the tokenize module to handle any encoding declaration. with tokenize.open(filename) as f: diff --git a/peps/pep-0724.rst b/peps/pep-0724.rst index 7ef23850b8b..89c6695df2b 100644 --- a/peps/pep-0724.rst +++ b/peps/pep-0724.rst @@ -348,3 +348,4 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. + diff --git a/peps/pep-0725.rst b/peps/pep-0725.rst index 52aa8d1c2fb..13fc866d6f7 100644 --- a/peps/pep-0725.rst +++ b/peps/pep-0725.rst @@ -104,7 +104,7 @@ Multiple types of external dependencies can be distinguished: Concrete packages are straightforward to understand, and are a concept present in virtually every package management system. Virtual packages are a concept also present in a number of packaging systems -- but not always, and the -details of their implementation varies. +details of their implementation varies. Cross compilation ----------------- @@ -186,7 +186,7 @@ The two types of concrete packages are supported by PURL_ (Package URL), which implements a scheme for identifying packages that is meant to be portable across packaging ecosystems. Its design is:: - scheme:type/namespace/name@version?qualifiers#subpath + scheme:type/namespace/name@version?qualifiers#subpath The ``scheme`` component is a fixed string, ``pkg``, and of the other components only ``type`` and ``name`` are required. As an example, a package diff --git a/peps/pep-0727.rst b/peps/pep-0727.rst index 8bc9a638e2d..a6663a87bda 100644 --- a/peps/pep-0727.rst +++ b/peps/pep-0727.rst @@ -346,14 +346,14 @@ For example: .. code:: java /** - * Returns an Image object that can then be painted on the screen. + * Returns an Image object that can then be painted on the screen. * The url argument must specify an absolute {@link URL}. The name - * argument is a specifier that is relative to the url argument. + * argument is a specifier that is relative to the url argument. *

- * This method always returns immediately, whether or not the + * This method always returns immediately, whether or not the * image exists. When this applet attempts to draw the image on - * the screen, the data will be loaded. The graphics primitives - * that draw the image will incrementally paint on the screen. + * the screen, the data will be loaded. The graphics primitives + * that draw the image will incrementally paint on the screen. * * @param url an absolute URL giving the base location of the image * @param name the location of the image, relative to the url argument diff --git a/peps/pep-0728.rst b/peps/pep-0728.rst index f68542604d5..e9556ce2c5a 100644 --- a/peps/pep-0728.rst +++ b/peps/pep-0728.rst @@ -48,7 +48,7 @@ Another possible use case for this is a sound way to class Movie(TypedDict): name: str director: str - + class Book(TypedDict): name: str author: str @@ -194,12 +194,12 @@ to the ``extra_items`` argument. For example:: class Movie(TypedDict, extra_items=bool): name: str - + a: Movie = {"name": "Blade Runner", "novel_adaptation": True} # OK b: Movie = { "name": "Blade Runner", "year": 1982, # Not OK. 'int' is not assignable to 'bool' - } + } Here, ``extra_items=bool`` specifies that items other than ``'name'`` have a value type of ``bool`` and are non-required. @@ -214,12 +214,12 @@ the ``extra_items`` argument:: def f(movie: Movie) -> None: reveal_type(movie["name"]) # Revealed type is 'str' reveal_type(movie["novel_adaptation"]) # Revealed type is 'bool' - + ``extra_items`` is inherited through subclassing:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class Movie(MovieBase): year: int @@ -315,7 +315,7 @@ function parameters still apply:: class Movie(TypedDict, extra_items=int): name: str - + def f(**kwargs: Unpack[Movie]) -> None: ... # Should be equivalent to: @@ -356,7 +356,7 @@ unless it is declared to be ``ReadOnly`` in the superclass:: class Parent(TypedDict, extra_items=int | None): pass - + class Child(Parent, extra_items=int): # Not OK. Like any other TypedDict item, extra_items's type cannot be changed Second, ``extra_items=T`` effectively defines the value type of any unnamed @@ -384,10 +384,10 @@ For example:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class AdaptedMovie(MovieBase): # Not OK. 'bool' is not assignable to 'int | None' adapted_from_novel: bool - + class MovieRequiredYear(MovieBase): # Not OK. Required key 'year' is not known to 'Parent' year: int | None @@ -478,7 +478,7 @@ checks:: class MovieDetails(TypedDict, extra_items=int | None): name: str year: NotRequired[int] - + details: MovieDetails = {"name": "Kill Bill Vol. 1", "year": 2003} movie: Movie = details # Not OK. While 'int' is assignable to 'int | None', # 'int | None' is not assignable to 'int' @@ -502,7 +502,7 @@ possible for an item to have a :term:`narrower ` type than the class Movie(TypedDict, extra_items=ReadOnly[str | int]): name: str - + class MovieDetails(TypedDict, extra_items=int): name: str year: NotRequired[int] @@ -522,19 +522,19 @@ enforced:: class MovieExtraStr(TypedDict, extra_items=str): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} extra_str: MovieExtraStr = {"name": "No Country for Old Men", "description": ""} extra_int = extra_str # Not OK. 'str' is not assignable to extra items type 'int' extra_str = extra_int # Not OK. 'int' is not assignable to extra items type 'str' - + A non-closed TypedDict type implicitly allows non-required extra keys of value type ``ReadOnly[object]``. Applying the assignability rules between this type and a closed TypedDict type is allowed:: class MovieNotClosed(TypedDict): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} not_closed: MovieNotClosed = {"name": "No Country for Old Men"} extra_int = not_closed # Not OK. @@ -636,8 +636,8 @@ For example:: def f(x: IntDict) -> None: v: dict[str, int] = x # OK v.clear() # OK - - not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} + + not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} regular_dict: dict[str, int] = not_required_num_dict # OK f(not_required_num_dict) # OK @@ -652,7 +652,7 @@ because such dict can be a subtype of dict:: class CustomDict(dict[str, int]): pass - + not_a_regular_dict: CustomDict = {"num": 1} int_dict: IntDict = not_a_regular_dict # Not OK diff --git a/peps/pep-0754.rst b/peps/pep-0754.rst index 94bab4fc0fd..d10565fc52d 100644 --- a/peps/pep-0754.rst +++ b/peps/pep-0754.rst @@ -209,7 +209,7 @@ Copyright This document has been placed in the public domain. - + .. Local Variables: mode: indented-text From a0fc70558a2defaf8be6968cdd3de3993804667f Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Tue, 22 Oct 2024 16:04:27 +0100 Subject: [PATCH 3/6] Be consistent in patterns --- .pre-commit-config.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 28d976b3dc2..b4b997989c0 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -23,7 +23,7 @@ repos: (?x)^peps/pep-( 02(30|47|65|72) |03(42|74) - |04(0[0459]|1[06]|45|51|68) + |04(00|04|05|09|10|16|45|51|68) |0524 |06(51|72|93|99) |07(05|13|24) @@ -37,7 +37,7 @@ repos: 0282 |0484 |05(17|44|63|82|86) - |061[1567]|062[56]|063[679]|064[356]|065[237]|066[029]|0679|0681|069[1245] + |06(11|15|16|17|25|26|36|37|39|43|45|46|52|53|57|60|62|69|79|81|91|92|94|95) |07(03|06|22|25|27|28) |3104 ).*\.rst$ From c232597d7d95a83b680e06fbcdc9c928d22af3af Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Tue, 22 Oct 2024 16:05:36 +0100 Subject: [PATCH 4/6] Consistently quote "args" --- .pre-commit-config.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index b4b997989c0..e824047d46e 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -31,7 +31,7 @@ repos: ).*\.rst$ - id: trailing-whitespace name: "Remove trailing whitespace" - args: [--chars, " \t"] + args: ["--chars", " \t"] exclude: | (?x)^peps/pep-( 0282 From bb47ceec11cff25c575bc4f9026e1e5a53c3299a Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Thu, 24 Oct 2024 18:06:53 +0100 Subject: [PATCH 5/6] Bin 'exclude' --- .pre-commit-config.yaml | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index e824047d46e..c13deaa95e2 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -19,28 +19,9 @@ repos: args: [--fix=lf] - id: end-of-file-fixer name: "Ensure files end with a single newline" - exclude: | - (?x)^peps/pep-( - 02(30|47|65|72) - |03(42|74) - |04(00|04|05|09|10|16|45|51|68) - |0524 - |06(51|72|93|99) - |07(05|13|24) - |31(11|18|33|46) - ).*\.rst$ - id: trailing-whitespace name: "Remove trailing whitespace" args: ["--chars", " \t"] - exclude: | - (?x)^peps/pep-( - 0282 - |0484 - |05(17|44|63|82|86) - |06(11|15|16|17|25|26|36|37|39|43|45|46|52|53|57|60|62|69|79|81|91|92|94|95) - |07(03|06|22|25|27|28) - |3104 - ).*\.rst$ - id: file-contents-sorter name: "Sort codespell ignore list" From 529ffba1b0b02c1ad7c3b6a85cc6989fab70f147 Mon Sep 17 00:00:00 2001 From: Adam Turner <9087854+aa-turner@users.noreply.github.com> Date: Thu, 24 Oct 2024 18:08:14 +0100 Subject: [PATCH 6/6] Bin 'exclude' (pt 2) --- peps/pep-0230.rst | 1 - peps/pep-0247.rst | 1 - peps/pep-0265.rst | 1 - peps/pep-0272.rst | 1 - peps/pep-0282.rst | 6 +- peps/pep-0342.rst | 1 - peps/pep-0374.rst | 1 - peps/pep-0400.rst | 1 - peps/pep-0404.rst | 1 - peps/pep-0405.rst | 1 - peps/pep-0409.rst | 1 - peps/pep-0410.rst | 1 - peps/pep-0416.rst | 1 - peps/pep-0445.rst | 1 - peps/pep-0451.rst | 1 - peps/pep-0468.rst | 1 - peps/pep-0484.rst | 2 +- peps/pep-0517.rst | 2 +- peps/pep-0524.rst | 1 - peps/pep-0544.rst | 2 +- peps/pep-0563.rst | 6 +- peps/pep-0582.rst | 2 +- peps/pep-0586.rst | 4 +- peps/pep-0611.rst | 8 +- peps/pep-0615.rst | 2 +- peps/pep-0616.rst | 4 +- peps/pep-0617.rst | 4 +- peps/pep-0625.rst | 2 +- peps/pep-0626.rst | 4 +- peps/pep-0636.rst | 12 +- peps/pep-0637.rst | 128 +++++++++++----------- peps/pep-0639/appendix-rejected-ideas.rst | 2 +- peps/pep-0643.rst | 2 +- peps/pep-0645.rst | 4 +- peps/pep-0646.rst | 2 +- peps/pep-0651.rst | 1 - peps/pep-0652.rst | 2 +- peps/pep-0653.rst | 2 +- peps/pep-0657.rst | 2 +- peps/pep-0660.rst | 8 +- peps/pep-0662.rst | 2 +- peps/pep-0669.rst | 10 +- peps/pep-0672.rst | 1 - peps/pep-0679.rst | 4 +- peps/pep-0681.rst | 36 +++--- peps/pep-0691.rst | 2 +- peps/pep-0692.rst | 30 ++--- peps/pep-0693.rst | 2 - peps/pep-0694.rst | 8 +- peps/pep-0695.rst | 20 ++-- peps/pep-0699.rst | 2 - peps/pep-0703.rst | 6 +- peps/pep-0705.rst | 1 - peps/pep-0706.rst | 2 +- peps/pep-0713.rst | 1 - peps/pep-0722.rst | 2 +- peps/pep-0724.rst | 1 - peps/pep-0725.rst | 4 +- peps/pep-0727.rst | 10 +- peps/pep-0728.rst | 34 +++--- peps/pep-3104.rst | 2 +- peps/pep-3111.rst | 2 - peps/pep-3118.rst | 1 - peps/pep-3133.rst | 1 - peps/pep-3146.rst | 3 - 65 files changed, 192 insertions(+), 224 deletions(-) diff --git a/peps/pep-0230.rst b/peps/pep-0230.rst index d521a693800..ffc101e8744 100644 --- a/peps/pep-0230.rst +++ b/peps/pep-0230.rst @@ -407,4 +407,3 @@ Implementation Here's a prototype implementation: http://sourceforge.net/patch/?func=detailpatch&patch_id=102715&group_id=5470 - diff --git a/peps/pep-0247.rst b/peps/pep-0247.rst index 97b4c4f2ad1..b66ac3a60a6 100644 --- a/peps/pep-0247.rst +++ b/peps/pep-0247.rst @@ -170,4 +170,3 @@ This document has been placed in the public domain. mode: indented-text indent-tabs-mode: nil End: - diff --git a/peps/pep-0265.rst b/peps/pep-0265.rst index af4a55841b5..aec6588a071 100644 --- a/peps/pep-0265.rst +++ b/peps/pep-0265.rst @@ -204,4 +204,3 @@ Copyright ========= This document has been placed in the public domain. - diff --git a/peps/pep-0272.rst b/peps/pep-0272.rst index b7e2df854b0..b54e6331a52 100644 --- a/peps/pep-0272.rst +++ b/peps/pep-0272.rst @@ -241,4 +241,3 @@ This document has been placed in the public domain. mode: indented-text indent-tabs-mode: nil End: - diff --git a/peps/pep-0282.rst b/peps/pep-0282.rst index 36c6730eb10..14b464ad3f1 100644 --- a/peps/pep-0282.rst +++ b/peps/pep-0282.rst @@ -74,7 +74,7 @@ used to generate simple logging output on stderr. raise TypeError, "Bogus type error for testing" ----------------------------------------------------- -.. code-block:: python +.. code-block:: python --------- myapp.py ---------------------------------- import mymodule, logging @@ -91,7 +91,7 @@ used to generate simple logging output on stderr. log.info("Ending my app") ----------------------------------------------------- -.. code-block:: console +.. code-block:: console $ python myapp.py @@ -111,7 +111,7 @@ The above example shows the default output format. All aspects of the output format should be configurable, so that you could have output formatted like this: -.. code-block:: text +.. code-block:: text 2002-04-19 07:56:58,174 MyModule DEBUG - Doin' stuff... diff --git a/peps/pep-0342.rst b/peps/pep-0342.rst index 4570a1bd1af..3388e0c40e1 100644 --- a/peps/pep-0342.rst +++ b/peps/pep-0342.rst @@ -605,4 +605,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0374.rst b/peps/pep-0374.rst index 49c944e8ff0..2fbaf1c9084 100644 --- a/peps/pep-0374.rst +++ b/peps/pep-0374.rst @@ -1515,4 +1515,3 @@ Copyright ========= This document has been placed in the public domain. - diff --git a/peps/pep-0400.rst b/peps/pep-0400.rst index 5067e5a4ee5..75d8b9a4055 100644 --- a/peps/pep-0400.rst +++ b/peps/pep-0400.rst @@ -331,4 +331,3 @@ Footnotes .. [#f1] StreamReaderWriter has two more attributes than TextIOWrapper, reader and writer. - diff --git a/peps/pep-0404.rst b/peps/pep-0404.rst index 75c0119d47b..873a6939b41 100644 --- a/peps/pep-0404.rst +++ b/peps/pep-0404.rst @@ -180,4 +180,3 @@ This document has been placed in the public domain. .. _`2to3`: http://docs.python.org/library/2to3.html .. _differences: http://docs.python.org/release/3.0.1/whatsnew/3.0.html .. _porting: http://python3porting.com/ - diff --git a/peps/pep-0405.rst b/peps/pep-0405.rst index 8c95d1c1dc6..73d937e307a 100644 --- a/peps/pep-0405.rst +++ b/peps/pep-0405.rst @@ -533,4 +533,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0409.rst b/peps/pep-0409.rst index d8c05546700..35d8a2e84cc 100644 --- a/peps/pep-0409.rst +++ b/peps/pep-0409.rst @@ -204,4 +204,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0410.rst b/peps/pep-0410.rst index 715573e3bc9..a3c19afa7ee 100644 --- a/peps/pep-0410.rst +++ b/peps/pep-0410.rst @@ -544,4 +544,3 @@ Copyright ========= This document has been placed in the public domain. - diff --git a/peps/pep-0416.rst b/peps/pep-0416.rst index 59e2e4d08b8..68e85bb50be 100644 --- a/peps/pep-0416.rst +++ b/peps/pep-0416.rst @@ -251,4 +251,3 @@ Copyright ========= This document has been placed in the public domain. - diff --git a/peps/pep-0445.rst b/peps/pep-0445.rst index 996a54cdc7d..d24085e11a2 100644 --- a/peps/pep-0445.rst +++ b/peps/pep-0445.rst @@ -770,4 +770,3 @@ Copyright ========= This document has been placed into the public domain. - diff --git a/peps/pep-0451.rst b/peps/pep-0451.rst index be1fa1718e4..828ee76781e 100644 --- a/peps/pep-0451.rst +++ b/peps/pep-0451.rst @@ -957,4 +957,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0468.rst b/peps/pep-0468.rst index a7d2277b6c6..725b14216fc 100644 --- a/peps/pep-0468.rst +++ b/peps/pep-0468.rst @@ -438,4 +438,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0484.rst b/peps/pep-0484.rst index b3c24d5abbf..d98684ec292 100644 --- a/peps/pep-0484.rst +++ b/peps/pep-0484.rst @@ -128,7 +128,7 @@ have a return annotation; the default behavior is thus the same as for other methods.) A type checker is expected to check the body of a checked function for -consistency with the given annotations. The annotations may also be +consistency with the given annotations. The annotations may also be used to check correctness of calls appearing in other checked functions. Type checkers are expected to attempt to infer as much information as diff --git a/peps/pep-0517.rst b/peps/pep-0517.rst index a37f5aaf9d1..348e66423c5 100644 --- a/peps/pep-0517.rst +++ b/peps/pep-0517.rst @@ -375,7 +375,7 @@ configuration into individual package builds. Build backends MAY assign any semantics they like to this dictionary. Build frontends SHOULD provide some mechanism for users to specify arbitrary string-key/string-value pairs to be placed in this dictionary. -For example, they might support some syntax like ``--package-config CC=gcc``. +For example, they might support some syntax like ``--package-config CC=gcc``. In case a user provides duplicate string-keys, build frontends SHOULD combine the corresponding string-values into a list of strings. Build frontends MAY also provide arbitrary other mechanisms diff --git a/peps/pep-0524.rst b/peps/pep-0524.rst index 03ff8d89c40..05762c2cb2e 100644 --- a/peps/pep-0524.rst +++ b/peps/pep-0524.rst @@ -561,4 +561,3 @@ Copyright ========= This document has been placed in the public domain. - diff --git a/peps/pep-0544.rst b/peps/pep-0544.rst index 3b0ec6af333..cf0947ef65c 100644 --- a/peps/pep-0544.rst +++ b/peps/pep-0544.rst @@ -369,7 +369,7 @@ Examples:: def __init__(self, name: str, value: int) -> None: self.name = name self.value = value - + def method(self) -> None: return diff --git a/peps/pep-0563.rst b/peps/pep-0563.rst index 307c5a69029..20b0d1909e6 100644 --- a/peps/pep-0563.rst +++ b/peps/pep-0563.rst @@ -263,8 +263,8 @@ valid. They can use local names or the fully qualified name. Example:: def method(self) -> C.D.field2: # this is OK ... - def method(self) -> D.field2: # this FAILS, class D is local to C - ... # and is therefore only available + def method(self) -> D.field2: # this FAILS, class D is local to C + ... # and is therefore only available # as C.D. This was already true # before the PEP. @@ -273,7 +273,7 @@ valid. They can use local names or the fully qualified name. Example:: def method(self) -> field: # this FAILS, field is local to C and # is therefore not visible to D unless - # accessed as C.field. This was already + # accessed as C.field. This was already # true before the PEP. In the presence of an annotation that isn't a syntactically valid diff --git a/peps/pep-0582.rst b/peps/pep-0582.rst index ff4c987b538..1024aee4046 100644 --- a/peps/pep-0582.rst +++ b/peps/pep-0582.rst @@ -86,7 +86,7 @@ startup. When the interactive interpreter starts, if a ``__pypackages__`` directory is found in the current working directory, then it will be included in ``sys.path`` after the entry for current working directory and just before the -system site-packages. +system site-packages. When the interpreter runs a script, Python will try to find ``__pypackages__`` in the same directory as the script. If found (along with the current Python diff --git a/peps/pep-0586.rst b/peps/pep-0586.rst index 4dd36e6f0fa..39ba7a9067a 100644 --- a/peps/pep-0586.rst +++ b/peps/pep-0586.rst @@ -258,7 +258,7 @@ allowing them in future extensions of this PEP. - Floats: e.g. ``Literal[3.14]``. Representing Literals of infinity or NaN in a clean way is tricky; real-world APIs are unlikely to vary their behavior based on a float parameter. - + - Any: e.g. ``Literal[Any]``. ``Any`` is a type, and ``Literal[...]`` is meant to contain values only. It is also unclear what ``Literal[Any]`` would actually semantically mean. @@ -584,7 +584,7 @@ involving Literal bools. For example, we can combine ``Literal[True]``, scalar += 3 # Type checks: type of 'scalar' is narrowed to 'int' else: scalar += "foo" # Type checks: type of 'scalar' is narrowed to 'str' - + Interactions with Final ----------------------- diff --git a/peps/pep-0611.rst b/peps/pep-0611.rst index e267f6a6eaf..d1a1074d94e 100644 --- a/peps/pep-0611.rst +++ b/peps/pep-0611.rst @@ -5,7 +5,7 @@ Status: Withdrawn Type: Standards Track Content-Type: text/x-rst Created: 05-Dec-2019 -Post-History: +Post-History: Abstract @@ -16,7 +16,7 @@ for various aspects of Python code and its implementation. The Python language does not specify limits for many of its features. Not having any limit to these values seems to enhance programmer freedom, at least superficially, but in practice the CPython VM and other Python virtual -machines have implicit limits or are forced to assume that the limits are +machines have implicit limits or are forced to assume that the limits are astronomical, which is expensive. This PR lists a number of features which are to have a limit of one million. @@ -36,7 +36,7 @@ It is inefficient as actual values rarely need more than a dozen or so bits to r It is unsafe as malicious or poorly generated code could cause values to exceed 2\ :sup:`32`. -For example, line numbers are represented by 32 bit values internally. +For example, line numbers are represented by 32 bit values internally. This is inefficient, given that modules almost never exceed a few thousand lines. Despite being inefficient, it is still vulnerable to overflow as it is easy for an attacker to created a module with billions of newline characters. @@ -73,7 +73,7 @@ Imposing a limit on values such as lines of code in a module, and the number of has significant advantages for ease of implementation and efficiency of virtual machines. If the limit is sufficiently large, there is no adverse effect on users of the language. -By selecting a fixed but large limit for these values, +By selecting a fixed but large limit for these values, it is possible to have both safety and efficiency whilst causing no inconvenience to human programmers and only very rare problems for code generators. diff --git a/peps/pep-0615.rst b/peps/pep-0615.rst index 9bdad194107..87bc85f02c2 100644 --- a/peps/pep-0615.rst +++ b/peps/pep-0615.rst @@ -188,7 +188,7 @@ of the interpreter, it must not invalidate any caches or modify any existing ``ZoneInfo`` objects. Newly constructed ``ZoneInfo`` objects, however, should come from the updated data source. -This means that the point at which the data source is updated for new +This means that the point at which the data source is updated for new invocations of the ``ZoneInfo`` constructor depends primarily on the semantics of the caching behavior. The only guaranteed way to get a ``ZoneInfo`` object from an updated data source is to induce a cache miss, either by bypassing the diff --git a/peps/pep-0616.rst b/peps/pep-0616.rst index 73b915100d3..8ea0dc72ea1 100644 --- a/peps/pep-0616.rst +++ b/peps/pep-0616.rst @@ -294,11 +294,11 @@ built-in functions, a common theme is that if a beginner finds themselves manually indexing or slicing a string, then they should consider whether there is a higher-level method that better communicates *what* the code should do rather than merely *how* the -code should do it. The proposed ``removeprefix()`` and +code should do it. The proposed ``removeprefix()`` and ``removesuffix()`` methods expand the high-level string "toolbox" and further allow for this sort of skepticism toward manual slicing. -The main opportunity for user confusion will be the conflation of +The main opportunity for user confusion will be the conflation of ``lstrip``/``rstrip`` with ``removeprefix``/``removesuffix``. It may therefore be helpful to emphasize (as the documentation will) the following differences between the methods: diff --git a/peps/pep-0617.rst b/peps/pep-0617.rst index 8de9ca913f9..ecc376d3261 100644 --- a/peps/pep-0617.rst +++ b/peps/pep-0617.rst @@ -623,7 +623,7 @@ A similar grammar written to target Python AST objects: .. code:: PEG start: expr NEWLINE? ENDMARKER { ast.Expression(expr) } - expr: + expr: | expr '+' term { ast.BinOp(expr, ast.Add(), term) } | expr '-' term { ast.BinOp(expr, ast.Sub(), term) } | term { term } @@ -637,7 +637,7 @@ A similar grammar written to target Python AST objects: | '(' expr ')' { expr } | atom { atom } - atom: + atom: | NAME { ast.Name(id=name.string, ctx=ast.Load()) } | NUMBER { ast.Constant(value=ast.literal_eval(number.string)) } diff --git a/peps/pep-0625.rst b/peps/pep-0625.rst index a49d08488e8..357831ed185 100644 --- a/peps/pep-0625.rst +++ b/peps/pep-0625.rst @@ -67,7 +67,7 @@ the metadata available in the filename. This PEP also serves as the formal specification to the long-standing filename convention used by the current sdist implementations. The filename contains the distribution name and version, to aid tools identifying a -distribution without needing to download, unarchive the file, and perform +distribution without needing to download, unarchive the file, and perform costly metadata generation for introspection, if all the information they need is available in the filename. diff --git a/peps/pep-0626.rst b/peps/pep-0626.rst index afc6f3c6714..b497ebbf0ee 100644 --- a/peps/pep-0626.rst +++ b/peps/pep-0626.rst @@ -77,7 +77,7 @@ All expressions and parts of expressions are considered to be executable code. In general, all statements are also considered to be executable code. However, when a statement is spread over several lines, we must consider which parts of a statement are considered to be executable code. -Statements are made up of keywords and expressions. Not all keywords have a direct runtime effect, so not all keywords are considered to be executable code. +Statements are made up of keywords and expressions. Not all keywords have a direct runtime effect, so not all keywords are considered to be executable code. For example, ``else``, is a necessary part of an ``if`` statement, but there is no runtime effect associated with an ``else``. For the purposes of tracing, the following keywords will *not* be considered to be executable code: @@ -304,7 +304,7 @@ The ``PyLineTable_`` functions do not call into the C-API, so can be safely copi The ``PyCodeAddressRange`` struct will not be changed, but the ``_opaque`` struct is not part of the specification and may change. .. note:: - The ``PyCodeAddressRange`` struct has changed from the original version of this PEP, where the addition fields were defined, but + The ``PyCodeAddressRange`` struct has changed from the original version of this PEP, where the addition fields were defined, but were liable to change. For example, the following code prints out all the address ranges: diff --git a/peps/pep-0636.rst b/peps/pep-0636.rst index 3f9353aacc9..de5e42330a3 100644 --- a/peps/pep-0636.rst +++ b/peps/pep-0636.rst @@ -164,7 +164,7 @@ Adding a wildcard ------------------ You may want to print an error message saying that the command wasn't recognized when -all the patterns fail. You could use the feature we just learned and write +all the patterns fail. You could use the feature we just learned and write ``case [*ignored_words]`` as your last pattern. There's however a much simpler way:: match command.split(): @@ -312,7 +312,7 @@ different kinds of objects, and also apply patterns to its attributes:: game.go_north() ... case KeyPress(): - pass # Ignore other keystrokes + pass # Ignore other keystrokes case other_event: raise ValueError(f"Unrecognized event: {other_event}") @@ -417,13 +417,13 @@ mappings based on their present keys. In this case you could use:: The keys in your mapping pattern need to be literals, but the values can be any pattern. As in sequence patterns, all subpatterns have to match for the general -pattern to match. +pattern to match. You can use ``**rest`` within a mapping pattern to capture additional keys in the subject. Note that if you omit this, extra keys in the subject will be -ignored while matching, i.e. the message +ignored while matching, i.e. the message ``{"text": "foo", "color": "red", "style": "bold"}`` will match the first pattern -in the example above. +in the example above. Matching builtin classes ------------------------ @@ -433,7 +433,7 @@ source, the types of the field could be wrong, leading to bugs or security issue Any class is a valid match target, and that includes built-in classes like ``bool`` ``str`` or ``int``. That allows us to combine the code above with a class pattern. -So instead of writing ``{"text": message, "color": c}`` we can use +So instead of writing ``{"text": message, "color": c}`` we can use ``{"text": str() as message, "color": str() as c}`` to ensure that ``message`` and ``c`` are both strings. For many builtin classes (see :pep:`634` for the whole list), you can use a positional parameter as a shorthand, writing ``str(c)`` rather than ``str() as c``. diff --git a/peps/pep-0637.rst b/peps/pep-0637.rst index 100fe9f7821..9a2927f90c3 100644 --- a/peps/pep-0637.rst +++ b/peps/pep-0637.rst @@ -121,7 +121,7 @@ specification would improve notation and provide additional value: >>> ds["empty"].loc[dict(lon=5, lat=6)] = 10 >>> # new syntax >>> ds["empty"][lon=5, lat=6] = 10 - + >>> # old syntax >>> ds["empty"].loc[dict(lon=slice(1, 5), lat=slice(3, None))] = 10 >>> # new syntax @@ -307,13 +307,13 @@ The successful implementation of this PEP will result in the following behavior: obj[index] # calls type(obj).__getitem__(obj, index) - + obj[index] = value # calls type(obj).__setitem__(obj, index, value) - + del obj[index] # calls type(obj).__delitem__(obj, index) - + This remains the case even if the index is followed by keywords; see point 5 below. 3. Comma-separated arguments are still parsed as a tuple and passed as @@ -321,10 +321,10 @@ The successful implementation of this PEP will result in the following behavior: obj[spam, eggs] # calls type(obj).__getitem__(obj, (spam, eggs)) - + obj[spam, eggs] = value # calls type(obj).__setitem__(obj, (spam, eggs), value) - + del obj[spam, eggs] # calls type(obj).__delitem__(obj, (spam, eggs)) @@ -343,10 +343,10 @@ The successful implementation of this PEP will result in the following behavior: function calls. Examples:: # Single index with keywords: - + obj[index, spam=1, eggs=2] # calls type(obj).__getitem__(obj, index, spam=1, eggs=2) - + obj[index, spam=1, eggs=2] = value # calls type(obj).__setitem__(obj, index, value, spam=1, eggs=2) @@ -397,7 +397,7 @@ The successful implementation of this PEP will result in the following behavior: obj[*items] - This allows notations such as ``[:, *args, :]``, which could be treated + This allows notations such as ``[:, *args, :]``, which could be treated as ``[(slice(None), *args, slice(None))]``. Multiple star unpacking are allowed:: @@ -406,20 +406,20 @@ The successful implementation of this PEP will result in the following behavior: The following notation equivalence must be honored:: - obj[*()] + obj[*()] # Equivalent to obj[()] - - obj[*(), foo=3] + + obj[*(), foo=3] # Equivalent to obj[(), foo=3] - obj[*(x,)] + obj[*(x,)] # Equivalent to obj[(x,)] - - obj[*(x,),] + + obj[*(x,),] # Equivalent to obj[(x,)] - Note in particular case 3: sequence unpacking of a single element will - not behave as if only one single argument was passed. A related case is + Note in particular case 3: sequence unpacking of a single element will + not behave as if only one single argument was passed. A related case is the following example:: obj[1, *(), foo=5] @@ -434,7 +434,7 @@ The successful implementation of this PEP will result in the following behavior: In other words, a single positional index will be passed "as is" only if no sequence unpacking is present. If a sequence unpacking is present, then the index will become a tuple, regardless of the resulting number of elements in the index after the unpacking has taken place. - + 8. Dict unpacking is permitted:: items = {'spam': 1, 'eggs': 2} @@ -443,20 +443,20 @@ The successful implementation of this PEP will result in the following behavior: The following notation equivalent should be honored:: - obj[**{}] + obj[**{}] # Equivalent to obj[()] - - obj[3, **{}] + + obj[3, **{}] # Equivalent to obj[3] 9. Keyword-only subscripts are permitted. The positional index will be the empty tuple:: obj[spam=1, eggs=2] # calls type(obj).__getitem__(obj, (), spam=1, eggs=2) - + obj[spam=1, eggs=2] = 5 # calls type(obj).__setitem__(obj, (), 5, spam=1, eggs=2) - + del obj[spam=1, eggs=2] # calls type(obj).__delitem__(obj, (), spam=1, eggs=2) @@ -567,7 +567,7 @@ With the introduction of the new notation, a few corner cases need to be analyse In other words, adding a keyword to a single-valued subscript will not change it into a tuple. For those cases where an actual tuple needs to be passed, a proper syntax will have to be used:: - obj[(1,), a=3] + obj[(1,), a=3] # calls type(obj).__getitem__(obj, (1,), a=3) In this case, the call is passing a single element (which is passed as is, as from rule above), @@ -578,16 +578,16 @@ With the introduction of the new notation, a few corner cases need to be analyse When keywords are present, the rule that you can omit this outermost pair of parentheses is no longer true:: - obj[1] + obj[1] # calls type(obj).__getitem__(obj, 1) - - obj[1, a=3] + + obj[1, a=3] # calls type(obj).__getitem__(obj, 1, a=3) - - obj[1,] + + obj[1,] # calls type(obj).__getitem__(obj, (1,)) - - obj[(1,), a=3] + + obj[(1,), a=3] # calls type(obj).__getitem__(obj, (1,), a=3) This is particularly relevant in the case where two entries are passed:: @@ -595,22 +595,22 @@ With the introduction of the new notation, a few corner cases need to be analyse obj[1, 2] # calls type(obj).__getitem__(obj, (1, 2)) - obj[(1, 2)] + obj[(1, 2)] # same as above - obj[1, 2, a=3] + obj[1, 2, a=3] # calls type(obj).__getitem__(obj, (1, 2), a=3) - - obj[(1, 2), a=3] + + obj[(1, 2), a=3] # calls type(obj).__getitem__(obj, (1, 2), a=3) And particularly when the tuple is extracted as a variable:: t = (1, 2) - obj[t] + obj[t] # calls type(obj).__getitem__(obj, (1, 2)) - obj[t, a=3] + obj[t, a=3] # calls type(obj).__getitem__(obj, (1, 2), a=3) Why? because in the case ``obj[1, 2, a=3]`` we are passing two elements (which @@ -641,7 +641,7 @@ implementation uses ``BINARY_SUBSCR``, ``STORE_SUBSCR`` and ``DELETE_SUBSCR`` to invoke the old functions. We propose ``BINARY_SUBSCR_KW``, ``STORE_SUBSCR_KW`` and ``DELETE_SUBSCR_KW`` for the new operations. The compiler will have to generate these new opcodes. The -old C implementations will call the extended methods passing ``NULL`` +old C implementations will call the extended methods passing ``NULL`` as kwargs. Finally, the following new slots must be added to the ``PyMappingMethods`` struct: @@ -744,7 +744,7 @@ helpers. class S: def __getitem__(self, key): return key - + s = S() defines the helper object ``s``. @@ -819,7 +819,7 @@ The problems with this approach were found to be: indexes. This would look awkward because the visual notation does not match the signature:: - obj[1, 2] = 3 + obj[1, 2] = 3 # calls type(obj).__setitem_ex__(obj, 3, 1, 2) - the solution relies on the assumption that all keyword indices necessarily map @@ -844,7 +844,7 @@ create a new "kwslice" object This proposal has already been explored in "New arguments contents" P4 in :pep:`472`:: - obj[a, b:c, x=1] + obj[a, b:c, x=1] # calls type(obj).__getitem__(obj, a, slice(b, c), key(x=1)) This solution requires everyone who needs keyword arguments to parse the tuple @@ -868,7 +868,7 @@ meaning that this:: would result in a call to:: - >>> type(obj).__getitem__(obj, 1, 2, z=3) + >>> type(obj).__getitem__(obj, 1, 2, z=3) # instead of type(obj).__getitem__(obj, (1, 2), z=3) This option has been rejected because it feels odd that a signature of a method @@ -902,14 +902,14 @@ This proposal already established that, in case no positional index is given, th passed value must be the empty tuple. Allowing for the empty index notation would make the dictionary type accept it automatically, to insert or refer to the value with the empty tuple as key. Moreover, a typing notation such as ``Tuple[]`` can easily -be written as ``Tuple`` without the indexing notation. +be written as ``Tuple`` without the indexing notation. However, subsequent discussion with Brandt Bucher during implementation has revealed -that the case ``obj[]`` would fit a natural evolution for variadic generics, giving +that the case ``obj[]`` would fit a natural evolution for variadic generics, giving more strength to the above comment. In the end, after a discussion between D'Aprano, Bucher and the author, we decided to leave the ``obj[]`` notation as a syntax error for now, and possibly extend the notation with an additional PEP to hold -the equivalence ``obj[]`` as ``obj[()]``. +the equivalence ``obj[]`` as ``obj[()]``. Sentinel value for no given positional index @@ -919,20 +919,20 @@ The topic of which value to pass as the index in the case of:: obj[k=3] -has been considerably debated. +has been considerably debated. One apparently rational choice would be to pass no value at all, by making use of the keyword only argument feature, but unfortunately will not work well with the ``__setitem__`` dunder, as a positional element for the value is always passed, and we can't "skip over" the index one unless we introduce a very weird behavior -where the first argument refers to the index when specified, and to the value when +where the first argument refers to the index when specified, and to the value when index is not specified. This is extremely deceiving and error prone. The above consideration makes it impossible to have a keyword only dunder, and opens up the question of what entity to pass for the index position when no index is passed:: - obj[k=3] = 5 + obj[k=3] = 5 # would call type(obj).__setitem__(obj, ???, 5, k=3) A proposed hack would be to let the user specify which entity to use when an @@ -969,7 +969,7 @@ positional only. Unfortunately, using positional-only values will ensure this does not happen but it will still not solve the need to pass both ``index`` and ``value`` even when the index is not provided. The point is that the user should not be prevented to use keyword arguments to refer to a column ``index``, ``value`` -(or ``self``) just because the class implementor happens to use those names +(or ``self``) just because the class implementor happens to use those names in the parameter list. Moreover, we also require the three dunders to behave in the same way: it would @@ -984,13 +984,13 @@ degenerate and thus impossible to differentiate in the dunder:: obj[k=3] obj[SENTINEL, k=3] -The question now shifts to which entity should represent the sentinel: +The question now shifts to which entity should represent the sentinel: the options were: 1. Empty tuple 2. None 3. NotImplemented -4. a new sentinel object (e.g. NoIndex) +4. a new sentinel object (e.g. NoIndex) For option 1, the call will become:: @@ -1000,7 +1000,7 @@ therefore making ``obj[k=3]`` and ``obj[(), k=3]`` degenerate and indistinguisha This option sounds appealing because: -1. The numpy community was inquired [#numpy-ml]_, and the general consensus +1. The numpy community was inquired [#numpy-ml]_, and the general consensus of the responses was that the empty tuple felt appropriate. 2. It shows a parallel with the behavior of ``*args`` in a function, when no positional arguments are given:: @@ -1011,7 +1011,7 @@ This option sounds appealing because: >>> foo(k=3) () {'k': 3} - Although we do accept the following asymmetry in behavior compared to functions + Although we do accept the following asymmetry in behavior compared to functions when a single value is passed, but that ship has sailed:: >>> foo(5, k=3) @@ -1030,13 +1030,13 @@ The only issues with both the above is that both the empty tuple and None are potential legitimate indexes, and there might be value in being able to differentiate the two degenerate cases. -So, an alternative strategy (option 3) would be to use an existing entity that is -unlikely to be used as a valid index. One option could be the current built-in constant +So, an alternative strategy (option 3) would be to use an existing entity that is +unlikely to be used as a valid index. One option could be the current built-in constant ``NotImplemented``, which is currently returned by operators methods to report that they do not implement a particular operation, and a different strategy should be attempted (e.g. to ask the other object). Unfortunately, its name and traditional use calls back to a feature that is not available, rather than the -fact that something was not passed by the user. +fact that something was not passed by the user. This leaves us with option 4: a new built-in constant. This constant must be unhashable (so it's never going to be a valid key) and have a clear @@ -1047,21 +1047,21 @@ From a quick inquire, it seems that most people on python-ideas seem to believe it's not crucial, and the empty tuple is an acceptable option. Hence the resulting series will be:: - obj[k=3] + obj[k=3] # type(obj).__getitem__(obj, (), k=3). Empty tuple - obj[1, k=3] + obj[1, k=3] # type(obj).__getitem__(obj, 1, k=3). Integer - obj[1, 2, k=3] + obj[1, 2, k=3] # type(obj).__getitem__(obj, (1, 2), k=3). Tuple and the following two notation will be degenerate:: - obj[(), k=3] + obj[(), k=3] # type(obj).__getitem__(obj, (), k=3) - obj[k=3] + obj[k=3] # type(obj).__getitem__(obj, (), k=3) Common objections @@ -1083,13 +1083,13 @@ Common objections but for obvious reasons, call syntax using builtins to create custom type hints isn't an option:: - dict(i=float, j=float) + dict(i=float, j=float) # would create a dictionary, not a type Finally, function calls do not allow for a setitem-like notation, as shown - in the Overview: operations such as ``f(1, x=3) = 5`` are not allowed, and are + in the Overview: operations such as ``f(1, x=3) = 5`` are not allowed, and are instead allowed for indexing operations. - + References ========== diff --git a/peps/pep-0639/appendix-rejected-ideas.rst b/peps/pep-0639/appendix-rejected-ideas.rst index 92681925dca..09321226c32 100644 --- a/peps/pep-0639/appendix-rejected-ideas.rst +++ b/peps/pep-0639/appendix-rejected-ideas.rst @@ -180,7 +180,7 @@ in line with the goals of PEP 639. While differences from existing tool formats (and Core Metadata field names) have precedent in :pep:`621`, repurposing an existing key to mean something different (and map to a different Core Metadata field), -with distinct and incompatible syntax does not, +with distinct and incompatible syntax does not, and could cause ambiguity for readers and authors. Also, per the `project source metadata spec `__, diff --git a/peps/pep-0643.rst b/peps/pep-0643.rst index 08fc1f67551..2df732adeb5 100644 --- a/peps/pep-0643.rst +++ b/peps/pep-0643.rst @@ -99,7 +99,7 @@ rules apply: 2. If a field is marked as ``Dynamic``, it may contain any valid value in a wheel built from the sdist (including not being present at all). 3. Backends MUST NOT mark a field as ``Dynamic`` if they can determine that - it was generated from data that will not change at build time. + it was generated from data that will not change at build time. Backends MAY record the value they calculated for a field they mark as ``Dynamic`` in a source distribution. Consumers, however, MUST NOT treat diff --git a/peps/pep-0645.rst b/peps/pep-0645.rst index 922f8e67031..043e4d62552 100644 --- a/peps/pep-0645.rst +++ b/peps/pep-0645.rst @@ -24,8 +24,8 @@ Using ``T?`` to mean ``T|None`` is also inconsistent with TypeScript where it roughly means ``NotRequired[T]``. Such inconsistency would likely confuse folks coming from TypeScript to Python. -The above represents the consensus of -`typing-sig `_ +The above represents the consensus of +`typing-sig `_ and the sponsor of this PEP. diff --git a/peps/pep-0646.rst b/peps/pep-0646.rst index d29f41c1bc3..5a380efa723 100644 --- a/peps/pep-0646.rst +++ b/peps/pep-0646.rst @@ -830,7 +830,7 @@ to the ``TypeVarTuple``: Ptang[str, bool, float] # T1=str, T3=float, T2=bool, Ts=Tuple[()] Ptang[str, bool, float, int] # T1=str, T3=int, T2=float, Ts=Tuple[bool] - + Note that the minimum number of type arguments in such cases is set by the number of ``TypeVar``\s: diff --git a/peps/pep-0651.rst b/peps/pep-0651.rst index a48715cdb70..2122b54dfbf 100644 --- a/peps/pep-0651.rst +++ b/peps/pep-0651.rst @@ -243,4 +243,3 @@ CC0-1.0-Universal license, whichever is more permissive. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0652.rst b/peps/pep-0652.rst index 19bdff9793a..09b8467c74d 100644 --- a/peps/pep-0652.rst +++ b/peps/pep-0652.rst @@ -307,7 +307,7 @@ Design considerations: * Make sure the ownership rules and lifetimes of all applicable struct fields, arguments and return values are well defined. -* Think about ease of use for the user. (In C, ease of use itself is not very +* Think about ease of use for the user. (In C, ease of use itself is not very important; what *is* useful is reducing boilerplate code needed to use the API. Bugs like to hide in boiler plates.) diff --git a/peps/pep-0653.rst b/peps/pep-0653.rst index bfb251122f4..e7228da5fb8 100644 --- a/peps/pep-0653.rst +++ b/peps/pep-0653.rst @@ -86,7 +86,7 @@ Looking up a special attribute is much faster than performing a subclass test on Rationale ========= -The object model and special methods are at the core of the Python language. Consequently, +The object model and special methods are at the core of the Python language. Consequently, implementations support them well. Using special attributes for pattern matching allows pattern matching to be implemented in a way that integrates well with the rest of the implementation, and is thus easier to maintain and is likely to perform better. diff --git a/peps/pep-0657.rst b/peps/pep-0657.rst index 94ce30dba98..bfe8342b48d 100644 --- a/peps/pep-0657.rst +++ b/peps/pep-0657.rst @@ -407,7 +407,7 @@ very difficult to debug for regular users and will make different pyc files incompatible between each other. As this pyc could be shipped as part of libraries or applications without the original source, it is also not always possible to force recompilation of said pyc files. For these reasons we have -decided to use the -O flag to opt-out of this behaviour. +decided to use the -O flag to opt-out of this behaviour. Lazy loading of column information ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/peps/pep-0660.rst b/peps/pep-0660.rst index 7547eadeb1e..a7c881d696e 100644 --- a/peps/pep-0660.rst +++ b/peps/pep-0660.rst @@ -8,7 +8,7 @@ Type: Standards Track Topic: Packaging Content-Type: text/x-rst Created: 30-Mar-2021 -Post-History: +Post-History: Resolution: https://discuss.python.org/t/pronouncement-on-peps-660-and-662-editable-installs/9450 @@ -83,12 +83,12 @@ The Mechanism This PEP adds three optional hooks to the :pep:`517` backend interface. These hooks are used to build a wheel that, when installed, allows that distribution to be -imported from its source folder. +imported from its source folder. build_editable -------------- -:: +:: def build_editable(wheel_directory, config_settings=None, metadata_directory=None): ... @@ -174,7 +174,7 @@ metadata directly. What to put in the wheel ------------------------ -Build backends must populate the generated wheel with files that when installed will result in an editable install. +Build backends must populate the generated wheel with files that when installed will result in an editable install. Build backends may use different techniques to achieve the goals of an editable install. This section provides examples and is not normative. diff --git a/peps/pep-0662.rst b/peps/pep-0662.rst index 54b83157d4a..7ca95582f81 100644 --- a/peps/pep-0662.rst +++ b/peps/pep-0662.rst @@ -62,7 +62,7 @@ each method of achieving editable effect has its pros and cons. Therefore this PEP rejects option three as it's unlikely for the community to agree on a single solution. Furthermore, question remains as to whether the frontend or the build backend should own this responsibility. :pep:`660` proposes the build -backend to own this, while the current PEP proposes primarily the frontend, +backend to own this, while the current PEP proposes primarily the frontend, but still allows the backend to take take control if it wants to do so. Rationale diff --git a/peps/pep-0669.rst b/peps/pep-0669.rst index 3aee69bfbfe..83f27ec0f71 100644 --- a/peps/pep-0669.rst +++ b/peps/pep-0669.rst @@ -44,7 +44,7 @@ Rationale The quickening mechanism provided by :pep:`659` provides a way to dynamically modify executing Python bytecode. These modifications have little cost beyond -the parts of the code that are modified and a relatively low cost to those +the parts of the code that are modified and a relatively low cost to those parts that are modified. We can leverage this to provide an efficient mechanism for monitoring that was not possible in 3.10 or earlier. @@ -152,7 +152,7 @@ The STOP_ITERATION event :pep:`PEP 380 <380#use-of-stopiteration-to-return-values>` specifies that a ``StopIteration`` exception is raised when returning a value -from a generator or coroutine. However, this is a very inefficient way to +from a generator or coroutine. However, this is a very inefficient way to return a value, so some Python implementations, notably CPython 3.12+, do not raise an exception unless it would be visible to other code. @@ -289,7 +289,7 @@ If a callback function returns ``DISABLE``, then that function will no longer be called for that ``(code, instruction_offset)`` until ``sys.monitoring.restart_events()`` is called. This feature is provided for coverage and other tools that are only interested -seeing an event once. +seeing an event once. Note that ``sys.monitoring.restart_events()`` is not specific to one tool, so tools must be prepared to receive events that they have chosen to DISABLE. @@ -470,7 +470,7 @@ registered callable. When the set of active events changes, the VM will immediately update all code objects present on the call stack of any thread. It will also set in place traps to ensure that all code objects are correctly instrumented when -called. Consequently changing the set of active events should be done as +called. Consequently changing the set of active events should be done as infrequently as possible, as it could be quite an expensive operation. Other events, such as ``RAISE`` can be turned on or off cheaply, @@ -570,7 +570,7 @@ events will have a large impact on performance. .. note:: - Instrumenting profilers have significant overhead and will distort + Instrumenting profilers have significant overhead and will distort the results of profiling. Unless you need exact call counts, consider using a statistical profiler. diff --git a/peps/pep-0672.rst b/peps/pep-0672.rst index 147a3c5bf16..4acab48a2a5 100644 --- a/peps/pep-0672.rst +++ b/peps/pep-0672.rst @@ -402,4 +402,3 @@ CC0-1.0-Universal license, whichever is more permissive. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-0679.rst b/peps/pep-0679.rst index ed941b8237a..3208063f3af 100644 --- a/peps/pep-0679.rst +++ b/peps/pep-0679.rst @@ -121,7 +121,7 @@ Backwards Compatibility The change is not technically backwards compatible, as parsing ``assert (x,y)`` is currently interpreted as an assert statement with a 2-tuple as the subject, -while after this change it will be interpreted as ``assert x,y``. +while after this change it will be interpreted as ``assert x,y``. On the other hand, assert statements of this kind always pass, so they are effectively not doing anything in user code. The authors of this document think @@ -141,7 +141,7 @@ How to Teach This The new form of the ``assert`` statement will be documented as part of the language standard. -When teaching the form with error message of the ``assert`` statement to users, +When teaching the form with error message of the ``assert`` statement to users, now it can be noted that adding parentheses also work as expected, which allows to break the statement over multiple lines. diff --git a/peps/pep-0681.rst b/peps/pep-0681.rst index 2463d766ef1..1fba9cb928d 100644 --- a/peps/pep-0681.rst +++ b/peps/pep-0681.rst @@ -149,7 +149,7 @@ Decorator function example .. code-block:: python _T = TypeVar("_T") - + # The ``create_model`` decorator is defined by a library. # This could be in a type stub or inline. @typing.dataclass_transform() @@ -158,7 +158,7 @@ Decorator function example cls.__eq__ = ... cls.__ne__ = ... return cls - + # The ``create_model`` decorator can now be used to create new model # classes, like this: @create_model @@ -191,9 +191,9 @@ Metaclass example # a library. This could be in a type stub or inline. @typing.dataclass_transform() class ModelMeta(type): ... - + class ModelBase(metaclass=ModelMeta): ... - + # The ``ModelBase`` class can now be used to create new model # subclasses, like this: class CustomerModel(ModelBase): @@ -211,7 +211,7 @@ these parameters accepts a bool argument, and it must be possible for the bool value (``True`` or ``False``) to be statically evaluated. * ``eq``, ``order``, ``frozen``, ``init`` and ``unsafe_hash`` are parameters - supported in the stdlib dataclass, with meanings defined in + supported in the stdlib dataclass, with meanings defined in :pep:`PEP 557 <557#id7>`. * ``kw_only``, ``match_args`` and ``slots`` are parameters supported in the stdlib dataclass, first introduced in Python 3.10. @@ -225,7 +225,7 @@ customization of default behaviors: .. code-block:: python _T = TypeVar("_T") - + def dataclass_transform( *, eq_default: bool = True, @@ -286,7 +286,7 @@ Decorator function example frozen: bool = False, kw_only: bool = True, ) -> Callable[[Type[_T]], Type[_T]]: ... - + # Example of how this decorator would be used by code that imports # from this library: @create_model(frozen=True, kw_only=False) @@ -312,7 +312,7 @@ Class example order: bool = True, ): ... - + # Example of how this class would be used by code that imports # from this library: class CustomerModel( @@ -346,10 +346,10 @@ Metaclass example order: bool = True, ): ... - + class ModelBase(metaclass=ModelMeta): ... - + # Example of how this class would be used by code that imports # from this library: class CustomerModel( @@ -381,14 +381,14 @@ not required: class Employee: # Field with no specifier name: str - + # Field that uses field specifier class instance age: Optional[int] = field(default=None, init=False) - + # Field with type annotation and simple initializer to # describe default value is_paid_hourly: bool = True - + # Not a field (but rather a class variable) because type # annotation is not provided. office_number = "unassigned" @@ -454,7 +454,7 @@ This example demonstrates the above: resolver: Callable[[], Any], init: Literal[False] = False, ) -> Any: ... - + @overload def model_field( *, @@ -462,7 +462,7 @@ This example demonstrates the above: resolver: None = None, init: bool = True, ) -> Any: ... - + @typing.dataclass_transform( kw_only_default=True, field_specifiers=(model_field, )) @@ -470,7 +470,7 @@ This example demonstrates the above: *, init: bool = True, ) -> Callable[[Type[_T]], Type[_T]]: ... - + # Code that imports this library: @create_model(init=False) class CustomerModel: @@ -519,7 +519,7 @@ This includes, but is not limited to, the following semantics: is considered neither frozen nor non-frozen. Consider these class examples: - + .. code-block:: python # ModelBase is not considered either "frozen" or "non-frozen" @@ -538,7 +538,7 @@ This includes, but is not limited to, the following semantics: wheel_count: int And these similar metaclass examples: - + .. code-block:: python @typing.dataclass_transform() diff --git a/peps/pep-0691.rst b/peps/pep-0691.rst index 0de7cfd7fb3..5b7a7b6f94b 100644 --- a/peps/pep-0691.rst +++ b/peps/pep-0691.rst @@ -515,7 +515,7 @@ Servers that implement the Simple API may choose to support an URL parameter nam ``format`` to allow the clients to request a specific version of the URL. The value of the ``format`` parameter should be **one** of the valid content types. -Passing multiple content types, wild cards, quality values, etc... is **not** +Passing multiple content types, wild cards, quality values, etc... is **not** supported. Supporting this parameter is optional, and clients **SHOULD NOT** rely on it for diff --git a/peps/pep-0692.rst b/peps/pep-0692.rst index 7b1f8d0a5be..23f192d2664 100644 --- a/peps/pep-0692.rst +++ b/peps/pep-0692.rst @@ -86,14 +86,14 @@ For instance:: class Movie(TypedDict): name: str year: int - + def foo(**kwargs: Movie) -> None: ... means that each keyword argument in ``foo`` is itself a ``Movie`` dictionary that has a ``name`` key with a string type value and a ``year`` key with an integer type value. Therefore, in order to support specifying ``kwargs`` type as a ``TypedDict`` without breaking current behaviour, a new construct has to -be introduced. +be introduced. To support this use case, we propose reusing ``Unpack`` which was initially introduced in :pep:`646`. There are several reasons for doing so: @@ -207,7 +207,7 @@ compatible:: class Animal(TypedDict): name: str - + class Dog(Animal): breed: str @@ -234,10 +234,10 @@ function arguments. Again, the rest of the parameters have to be compatible. Continuing the previous example:: class Example(TypedDict): - animal: Animal + animal: Animal string: str number: NotRequired[int] - + def src(**kwargs: Unpack[Example]): ... def dest(*, animal: Dog, string: str, number: int = ...): ... @@ -298,7 +298,7 @@ type ``T``:: class Vehicle: ... - + class Car(Vehicle): ... @@ -308,7 +308,7 @@ type ``T``:: class Vehicles(TypedDict): car: Car moto: Motorcycle - + def dest(**kwargs: Unpack[Vehicles]): ... def src(**kwargs: Vehicle): ... @@ -332,7 +332,7 @@ consider the following example:: class Animal(TypedDict): name: str - + class Dog(Animal): breed: str @@ -343,21 +343,21 @@ consider the following example:: def foo(**kwargs: Unpack[Animal]): print(kwargs["name"].capitalize()) - + def bar(**kwargs: Unpack[Animal]): takes_name(**kwargs) - + def baz(animal: Animal): takes_name(**animal) - + def spam(**kwargs: Unpack[Animal]): baz(kwargs) - + foo(**animal) # OK! foo only expects and uses keywords of 'Animal'. bar(**animal) # WRONG! This will fail at runtime because 'breed' keyword # will be passed to 'takes_name' as well. - + spam(**animal) # WRONG! Again, 'breed' keyword will be eventually passed # to 'takes_name'. @@ -462,7 +462,7 @@ Similar sections could be also added to the Reference Implementation ======================== -The `mypy type checker `_ already +The `mypy type checker `_ already `supports `_ more precise ``**kwargs`` typing using ``Unpack``. @@ -486,7 +486,7 @@ can result in an error:: class Book(TypedDict): genre: str pages: int - + TypedDictUnion = Movie | Book def foo(**kwargs: Unpack[TypedDictUnion]) -> None: ... # WRONG! Unsupported use diff --git a/peps/pep-0693.rst b/peps/pep-0693.rst index f8122e3d005..19ae6cfe8d4 100644 --- a/peps/pep-0693.rst +++ b/peps/pep-0693.rst @@ -99,5 +99,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - - diff --git a/peps/pep-0694.rst b/peps/pep-0694.rst index 30e3a32b8bd..b10c060366f 100644 --- a/peps/pep-0694.rst +++ b/peps/pep-0694.rst @@ -38,10 +38,10 @@ Beyond the above, there are a number of major issues with the current API: not go last, possibly some hard to build packages are attempting to be built from source. -- It has very limited support for communicating back to the user, with no support - for multiple errors, warnings, deprecations, etc. It is limited entirely to the - HTTP status code and reason phrase, of which the reason phrase has been - deprecated since HTTP/2 (:rfc:`RFC 7540 <7540#section-8.1.2.4>`). +- It has very limited support for communicating back to the user, with no support + for multiple errors, warnings, deprecations, etc. It is limited entirely to the + HTTP status code and reason phrase, of which the reason phrase has been + deprecated since HTTP/2 (:rfc:`RFC 7540 <7540#section-8.1.2.4>`). - The metadata for a release/file is submitted alongside the file, however this metadata is famously unreliable, and most installers instead choose to download diff --git a/peps/pep-0695.rst b/peps/pep-0695.rst index e8b9a3650d6..4f142e3ab9f 100644 --- a/peps/pep-0695.rst +++ b/peps/pep-0695.rst @@ -104,7 +104,7 @@ the developer to supply a redundant name in quotes (e.g. ``T = TypeVar("T")``). This PEP eliminates the need for the redundant name and cumbersome variable names. -Defining type parameters today requires importing the ``TypeVar`` and +Defining type parameters today requires importing the ``TypeVar`` and ``Generic`` symbols from the ``typing`` module. Over the past several releases of Python, efforts have been made to eliminate the need to import ``typing`` symbols for common use cases, and the PEP furthers this goal. @@ -320,7 +320,7 @@ Generic Type Alias We propose to introduce a new statement for declaring type aliases. Similar to ``class`` and ``def`` statements, a ``type`` statement defines a scope -for type parameters. +for type parameters. :: @@ -476,7 +476,7 @@ Type parameter symbols defined in outer scopes cannot be bound with T = 1 def outer2[T](): - + def inner1(): nonlocal S # OK because it binds variable S from outer1 nonlocal T # Syntax error: nonlocal binding not allowed for type parameter @@ -664,7 +664,7 @@ Here is an example. class ClassA[T1, T2, T3](list[T1]): def method1(self, a: T2) -> None: ... - + def method2(self) -> T3: ... @@ -775,7 +775,7 @@ in the following ways: 1. Addition of optional type parameter clause in ``class`` and ``def`` statements. :: - + type_params: '[' t=type_param_seq ']' type_param_seq: a[asdl_typeparam_seq*]=','.type_param+ [','] @@ -1156,7 +1156,7 @@ in Python requires this. A few other languages including Scala and C# also require developers to specify the variance. We rejected this idea because variance can generally be inferred, and most modern programming languages do infer variance based on usage. Variance is an advanced topic that -many developers find confusing, so we want to eliminate the need to +many developers find confusing, so we want to eliminate the need to understand this concept for most Python developers. @@ -1264,7 +1264,7 @@ Java provides no way to specify a default type argument. // Use site variance public void method1(ClassA value) { } } - + C# -- @@ -1301,7 +1301,7 @@ C# provides no way to specify a default type argument. TypeScript ---------- -TypeScript uses angle brackets to declare type parameters and for +TypeScript uses angle brackets to declare type parameters and for specialization. The ``extends`` keyword is used to specify a bound. It can be combined with other type operators such as ``keyof``. @@ -1316,7 +1316,7 @@ TypeScript supports the ``type`` keyword to declare a type alias, and this syntax supports generics. .. code-block:: typescript - + // Generic interface interface InterfaceA { val1: S; @@ -1356,7 +1356,7 @@ type parameters). .. code-block:: scala - + // Generic class; type parameter has upper bound class ClassA[A <: SomeClass1] { diff --git a/peps/pep-0699.rst b/peps/pep-0699.rst index 75bd3e30e3d..9e1b6ff8620 100644 --- a/peps/pep-0699.rst +++ b/peps/pep-0699.rst @@ -110,5 +110,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - - diff --git a/peps/pep-0703.rst b/peps/pep-0703.rst index 587819766e0..3277ab688ac 100644 --- a/peps/pep-0703.rst +++ b/peps/pep-0703.rst @@ -713,7 +713,7 @@ that wrap those calls. Python objects should not be allocated through other APIs, such as raw calls to C's malloc or the C++ new operator. Additionally, ``PyObject_Malloc`` should be used only for allocating Python objects; it should not be used for allocating buffers, -storages, or other data structures that are not PyObjects. +storages, or other data structures that are not PyObjects. This PEP also imposes restrictions on the pluggable allocator API (``PyMem_SetAllocator``). When compiling without the GIL, allocators @@ -967,7 +967,7 @@ per-object locking -- another thread might modify the list leading to The problematic borrowed reference APIs are supplemented with functions that return "new references" but are otherwise -equivalent: +equivalent: * ``PyList_FetchItem(list, idx)`` for ``PyList_GetItem`` * ``PyDict_FetchItem(dict, key)`` for ``PyDict_GetItem`` @@ -1087,7 +1087,7 @@ and improve single-threaded performance. Although lock acquisition has low overhead compared to most operations, accessing individual elements of lists and dictionaries are fast operations (so the locking overhead is comparatively larger) and frequent (so the -overhead has more impact). +overhead has more impact). This section describes the challenges with implementing dictionary and list accesses without locking followed by a description of this PEP's diff --git a/peps/pep-0705.rst b/peps/pep-0705.rst index 5ba78e3f938..cae156d4127 100644 --- a/peps/pep-0705.rst +++ b/peps/pep-0705.rst @@ -581,4 +581,3 @@ Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0706.rst b/peps/pep-0706.rst index 5585a809b03..984b7555017 100644 --- a/peps/pep-0706.rst +++ b/peps/pep-0706.rst @@ -110,7 +110,7 @@ However, there are some issues with this approach: affect all subsequent operations on the same ``TarFile`` object. This behavior is fine for most uses, but despite that, it would be very surprising if ``TarFile.extractall`` did this by default. -- Calling ``getmembers`` can be expensive and it +- Calling ``getmembers`` can be expensive and it `requires a seekable archive `__. - When verifying members in advance, it may be necessary to track how each member would have changed the filesystem, e.g. how symlinks are being set up. diff --git a/peps/pep-0713.rst b/peps/pep-0713.rst index 65d117b1d2c..9547b497b31 100644 --- a/peps/pep-0713.rst +++ b/peps/pep-0713.rst @@ -204,4 +204,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0722.rst b/peps/pep-0722.rst index 9d421302711..ab252400dcc 100644 --- a/peps/pep-0722.rst +++ b/peps/pep-0722.rst @@ -231,7 +231,7 @@ reference implementation can be included here. from packaging.requirements import Requirement DEPENDENCY_BLOCK_MARKER = r"(?i)^#\s+script\s+dependencies:\s*$" - + def read_dependency_block(filename): # Use the tokenize module to handle any encoding declaration. with tokenize.open(filename) as f: diff --git a/peps/pep-0724.rst b/peps/pep-0724.rst index 89c6695df2b..7ef23850b8b 100644 --- a/peps/pep-0724.rst +++ b/peps/pep-0724.rst @@ -348,4 +348,3 @@ Copyright This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. - diff --git a/peps/pep-0725.rst b/peps/pep-0725.rst index 13fc866d6f7..52aa8d1c2fb 100644 --- a/peps/pep-0725.rst +++ b/peps/pep-0725.rst @@ -104,7 +104,7 @@ Multiple types of external dependencies can be distinguished: Concrete packages are straightforward to understand, and are a concept present in virtually every package management system. Virtual packages are a concept also present in a number of packaging systems -- but not always, and the -details of their implementation varies. +details of their implementation varies. Cross compilation ----------------- @@ -186,7 +186,7 @@ The two types of concrete packages are supported by PURL_ (Package URL), which implements a scheme for identifying packages that is meant to be portable across packaging ecosystems. Its design is:: - scheme:type/namespace/name@version?qualifiers#subpath + scheme:type/namespace/name@version?qualifiers#subpath The ``scheme`` component is a fixed string, ``pkg``, and of the other components only ``type`` and ``name`` are required. As an example, a package diff --git a/peps/pep-0727.rst b/peps/pep-0727.rst index a6663a87bda..8bc9a638e2d 100644 --- a/peps/pep-0727.rst +++ b/peps/pep-0727.rst @@ -346,14 +346,14 @@ For example: .. code:: java /** - * Returns an Image object that can then be painted on the screen. + * Returns an Image object that can then be painted on the screen. * The url argument must specify an absolute {@link URL}. The name - * argument is a specifier that is relative to the url argument. + * argument is a specifier that is relative to the url argument. *

- * This method always returns immediately, whether or not the + * This method always returns immediately, whether or not the * image exists. When this applet attempts to draw the image on - * the screen, the data will be loaded. The graphics primitives - * that draw the image will incrementally paint on the screen. + * the screen, the data will be loaded. The graphics primitives + * that draw the image will incrementally paint on the screen. * * @param url an absolute URL giving the base location of the image * @param name the location of the image, relative to the url argument diff --git a/peps/pep-0728.rst b/peps/pep-0728.rst index e9556ce2c5a..f68542604d5 100644 --- a/peps/pep-0728.rst +++ b/peps/pep-0728.rst @@ -48,7 +48,7 @@ Another possible use case for this is a sound way to class Movie(TypedDict): name: str director: str - + class Book(TypedDict): name: str author: str @@ -194,12 +194,12 @@ to the ``extra_items`` argument. For example:: class Movie(TypedDict, extra_items=bool): name: str - + a: Movie = {"name": "Blade Runner", "novel_adaptation": True} # OK b: Movie = { "name": "Blade Runner", "year": 1982, # Not OK. 'int' is not assignable to 'bool' - } + } Here, ``extra_items=bool`` specifies that items other than ``'name'`` have a value type of ``bool`` and are non-required. @@ -214,12 +214,12 @@ the ``extra_items`` argument:: def f(movie: Movie) -> None: reveal_type(movie["name"]) # Revealed type is 'str' reveal_type(movie["novel_adaptation"]) # Revealed type is 'bool' - + ``extra_items`` is inherited through subclassing:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class Movie(MovieBase): year: int @@ -315,7 +315,7 @@ function parameters still apply:: class Movie(TypedDict, extra_items=int): name: str - + def f(**kwargs: Unpack[Movie]) -> None: ... # Should be equivalent to: @@ -356,7 +356,7 @@ unless it is declared to be ``ReadOnly`` in the superclass:: class Parent(TypedDict, extra_items=int | None): pass - + class Child(Parent, extra_items=int): # Not OK. Like any other TypedDict item, extra_items's type cannot be changed Second, ``extra_items=T`` effectively defines the value type of any unnamed @@ -384,10 +384,10 @@ For example:: class MovieBase(TypedDict, extra_items=int | None): name: str - + class AdaptedMovie(MovieBase): # Not OK. 'bool' is not assignable to 'int | None' adapted_from_novel: bool - + class MovieRequiredYear(MovieBase): # Not OK. Required key 'year' is not known to 'Parent' year: int | None @@ -478,7 +478,7 @@ checks:: class MovieDetails(TypedDict, extra_items=int | None): name: str year: NotRequired[int] - + details: MovieDetails = {"name": "Kill Bill Vol. 1", "year": 2003} movie: Movie = details # Not OK. While 'int' is assignable to 'int | None', # 'int | None' is not assignable to 'int' @@ -502,7 +502,7 @@ possible for an item to have a :term:`narrower ` type than the class Movie(TypedDict, extra_items=ReadOnly[str | int]): name: str - + class MovieDetails(TypedDict, extra_items=int): name: str year: NotRequired[int] @@ -522,19 +522,19 @@ enforced:: class MovieExtraStr(TypedDict, extra_items=str): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} extra_str: MovieExtraStr = {"name": "No Country for Old Men", "description": ""} extra_int = extra_str # Not OK. 'str' is not assignable to extra items type 'int' extra_str = extra_int # Not OK. 'int' is not assignable to extra items type 'str' - + A non-closed TypedDict type implicitly allows non-required extra keys of value type ``ReadOnly[object]``. Applying the assignability rules between this type and a closed TypedDict type is allowed:: class MovieNotClosed(TypedDict): name: str - + extra_int: MovieExtraInt = {"name": "No Country for Old Men", "year": 2007} not_closed: MovieNotClosed = {"name": "No Country for Old Men"} extra_int = not_closed # Not OK. @@ -636,8 +636,8 @@ For example:: def f(x: IntDict) -> None: v: dict[str, int] = x # OK v.clear() # OK - - not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} + + not_required_num_dict: IntDictWithNum = {"num": 1, "bar": 2} regular_dict: dict[str, int] = not_required_num_dict # OK f(not_required_num_dict) # OK @@ -652,7 +652,7 @@ because such dict can be a subtype of dict:: class CustomDict(dict[str, int]): pass - + not_a_regular_dict: CustomDict = {"num": 1} int_dict: IntDict = not_a_regular_dict # Not OK diff --git a/peps/pep-3104.rst b/peps/pep-3104.rst index 316ec3eb353..b74f1b63f53 100644 --- a/peps/pep-3104.rst +++ b/peps/pep-3104.rst @@ -527,7 +527,7 @@ References .. [30] Whatever happened to 'nonlocal x = y'? (Guido van Rossum) https://mail.python.org/pipermail/python-dev/2018-January/151627.html - + .. [31] Using and binding relative names (Almann T. Goo) https://mail.python.org/pipermail/python-dev/2006-February/061761.html diff --git a/peps/pep-3111.rst b/peps/pep-3111.rst index 947014ee967..5ef01168dad 100644 --- a/peps/pep-3111.rst +++ b/peps/pep-3111.rst @@ -157,5 +157,3 @@ Copyright ========= This document has been placed in the public domain. - - diff --git a/peps/pep-3118.rst b/peps/pep-3118.rst index b8d5f7cf749..1dd54e3890b 100644 --- a/peps/pep-3118.rst +++ b/peps/pep-3118.rst @@ -980,4 +980,3 @@ Copyright ========= This PEP is placed in the public domain. - diff --git a/peps/pep-3133.rst b/peps/pep-3133.rst index 45c41516093..d96528d04fa 100644 --- a/peps/pep-3133.rst +++ b/peps/pep-3133.rst @@ -561,4 +561,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - diff --git a/peps/pep-3146.rst b/peps/pep-3146.rst index dcbdbfe051d..c824b420fd7 100644 --- a/peps/pep-3146.rst +++ b/peps/pep-3146.rst @@ -1487,6 +1487,3 @@ This document has been placed in the public domain. fill-column: 70 coding: utf-8 End: - - -