PEP阅读摘要：四

• PEP-484 Type Hints

  This PEP aims to provide a standard syntax for type annotations.

  Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.

  This PEP still explicitly does Not prevent other uses of annotations, nor does it require(or forbid) any particular processing of annotations, even when they conform to this specification. It simply enables better coordination, as PEP 333 (Python Web Server Gateway Interface v1.0) did for web frameworks.

  def greeting(name: str) -> str:
      return "Hello" + name
  

  This proposal is strongly inspired by mypy.

• PEP517 – A build-system independent format for source trees

• PEP610 – Recording the Direct URL Origin of installed distributions

  A distribution can be identified by a name and either a version, or a direct URL reference. (see PEP440 Direct References [4])

  After installation, the name and version are captured in the project metadata, but currently there is no way to obtain details of the URL used when the distribution was identified by a direct URL reference.

• PEP458 – Secure PyPI downloads with signed repository metadata

• PEP544 – Protocols: Structural subtyping (static duck typing)

  Type hints introduced in PEP484 can be used to specify type metadata for static type checkers and other third party tools.

  However PEP484 only specifies the semantics of nominal subtyping.

  In this PEP we specify and runtime semantics of protocol classes that will provide a support for structural subtyping(static duck typing).

• PEP560 – Core support for typing module and generic types

• PEP561 – Distributing and Packaging Type Information

• PEP563 – Postponed Evaluation of Annotations

• PEP570 – Python Positional-Only Parameters

• PEP572 – Assignment Expressions

• PEP573 – Module State Access from C Extension Methods

• PEP578 – Python Runtime Audit Hooks

• PEP584 – Add Union Operators to dict

  This PEP proposes adding merge(|) and update(|=) operators to the built-in dict class.

  >>> d = {'spam': 1, 'eggs': 2, 'cheese': 3}
  >>> e = {'cheese': 'cheddar', 'aardvark': 'Ethel'}
  >>> d | e
  {'spam': 1, 'eggs': 2, 'cheese': 'cheddar', 'aardvark': 'Ethel'}
  >>> e | d
  {'aardvark': 'Ethel', 'spam': 1, 'eggs': 2, 'cheese': 3}
  

• PEP585 – Type Hinting Generics In Standard Collections

• PEP586 – Literal Types

  This PEP proposes adding Literal types to the PEP484 ecosystem.

• PEP589 – TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys

  This PEP proposes the addition of a new type constructor, called TypedDict, to allow the type of movie to be represented procisely.

• PEP590 – Vectorcall: a fast calling protocol for CPython

  This PEP introduces a new C API to optimize calls of objects.

  It introduces a new “vectorcall” protocol and calling convention.

  This is based on the “fastcall” convention, which is already used internally bu CPython.

• PEP591 – Adding a final qualifier to typing

  This PEP proposes a “final” qualifier ti be added to the typing module.

  from typing import final
  

• PEP593 – Flexible function and variable annotations

  This PEP introduces a mechanism to extend the type annotations from PEP484 with arbitrary metadata.

• PEP613 – Explicit Type Aliases

  Type aliases are user-specified types which may be as complex as any type hint, and are specified with a simple variable assignment on a moudle top level.

  THis PEP formalizes a way to explicitly declare an assignment as a type alias

• PEP614 – Relaxing Grammar Restrictions On Decorators

• PEP615 – Support for the IANA Time Zone Database in the Standard Library

• PEP616 – String methods to remove prefixes and suffixes

• PEP617 – New PEG parser for CPython

• PEP3121 – Extension Module Initialization and Finalization