Mar 18, 2017 · Mar 5, 2017 · Mar 5, 2017 · Mar 5, 2017 · Mar 6, 2017 · Mar 6, 2017
diff --git a/pep-05xx.txt b/pep-05xx.txt
 Rationale and Goals
 ===================

 Currently, PEP 484 and ``typing`` module define abstract base classes for
 several common Python protocols such as ``Iterable`` and ``Sized``.
 The problem with them is that a class has to be explicitly marked to support
 them, which is arguably unpythonic and unlike what one would normally do in
 idiomatic dynamically typed Python code. For example,
 Currently, PEP 484[pep484]_and ``typing`` module[typing]_define abstract
 base classes forseveral common Python protocols such as ``Iterable`` and
 ``Sized``.The problem with them is that a class has to be explicitly marked
 to supportthem, which is arguably unpythonic and unlike what one would
 normally do inidiomatic dynamically typed Python code. For example,
 this conforms to the PEP 484::

  from typing import Sized, Iterable, Iterator
 by allowing to write the above code without explicit base classes in
 the class definition, and ``Bucket`` would still be implicitly considered
 a subtype of both ``Sized`` and ``Iterable[int]`` by static type checkers
 using structural subtyping::
 using structural[wiki-structural-subtyping]_subtyping::

  from typing import Iterator

 The structural subtyping is natural for Python programmers since it matches
 the runtime semantics of duck typing: an object that has certain properties
 is treated independently of its actual runtime class.
 However, as discussed in PEP 483, both nominal and structural subtyping have
 their strengths and weaknesses. Therefore, in this PEPdo we not propose
 to replace the nominal subtyping described by PEP 484 with structural
 subtyping completely. Instead, it is proposed that the protocol classes
 complement normal classes, and the choice is left for a user to decide where
 to apply a particular solution. See section "Rejected ideas" for additional
 motivation.
 However, as discussed in PEP 483 [pep483]_, both nominal and structural
 subtyping havetheir strengths and weaknesses. Therefore, in this PEPwe
 *do not propose*to replace the nominal subtyping described by PEP 484 with
 structuralsubtyping completely. Instead, it is proposed that the protocol
 classescomplement normal classes, and the choice is left for a user to decide
 whereto apply a particular solution. See section "Rejected ideas" for
 additionalmotivation.


 Non-Goals
 This would be difficult and error-prone and will contradict the logic
 of PEP 484. As well, following PEP 484 and PEP 526 we state that protocols are
 **completely optional** and there is no intent to make them required.
 No runtime semantics will be imposed for variables or parameters annotated with
 a protocol class, the actual checks will be performed by third party type
 No runtime semantics will be imposed for variables or parameters annotated
 witha protocol class, the actual checks will be performed by third party type
 checkers and other tools.


 Before describing the actual specification, we review existing approaches
 related to structural subtyping in Python and other languages:

 * Zope interfaces was one of the first widely used approaches to
  structural subtyping in Python. It is implemented by providing special
  classes to distinguish interface classes from normal classes, to mark
  interface attributes and to explicitly declare implementation.
 * Zope interfaces[zope-interfaces]_was one of the first widely used
 approaches tostructural subtyping in Python. It is implemented by providing
 specialclasses to distinguish interface classes from normal classes,
 to markinterface attributes and to explicitly declare implementation.
  For example::

    from zope.interface import Interface, Attribute, implements
  with a special base class is reasonable and easy to implement both
  statically and at runtime.

 * Python abstract base classes are the standard library tool to provide some
  functionality similar to structural subtyping. The drawback of this
  approach is the necessity to either subclass the abstract class or
  register an implementation explicitly::
 * Python abstract base classes[abstract-base-classes]_are the standard
 library tool to provide somefunctionality similar to structural subtyping.
 The drawback of thisapproach is the necessity to either subclass
 the abstract class orregister an implementation explicitly::

    from abc import ABCMeta

  static context. However, in runtime context, ABCs are good candidates for
  protocol classes and are already used extensively in ``typing`` module.

 * Abstract classes defined in ``collections.abc`` module are slightly more
  advanced since they implement a custom ``__subclasshook__()`` method that
  allows runtime structural checks without explicit registration::
 * Abstract classes defined in ``collections.abc`` module [collections-abc]_
  are slightly more advanced since they implement a custom
  ``__subclasshook__()`` method that allows runtime structural checks without
  explicit registration::

    from collections.abc import Iterable

  that mimics the one in ``collections.abc``, see detailed specification
  below.

 * TypeScript provides support for user defined classes and interfaces.
  Explicit implementation declaration is not required, structural subtyping
  is verified statically. For example::
 * TypeScript[typescript]_provides support for user defined classes and
 interfaces.Explicit implementation declaration is not required,
 structural subtypingis verified statically. For example::

    interface LabelledItem {
        label: string;
  checking without runtime implications looks reasonable, and basically
  this proposal follows the same line.

 * Go uses a more radical approach and makes interfaces the primary way
  to provide type information. Also, assignments are used to explicitly
 * Go[golang]_uses a more radical approach and makes interfaces the primary
 wayto provide type information. Also, assignments are used to explicitly
  ensure implementation::

    type SomeInterface interface {
 defined in stub files. Abstract static methods, abstract class methods,
 and abstract properties are equally supported.

 To defined a protocol variable one should use the PEP 526 variable
 To defined a protocol variable one should use the PEP 526[pep526]_variable
 annotations in the class body. Attributes defined in the body of a method
 by assignment via ``self`` considered non-protocol members. The rationale for
 this is that the protocol class implementation is often not shared by
  from ``__annotations__`` to ``__subclsshook__()``.
 * In the backported version of ``typing``, translate ``...`` class attribute
  values to abstract properties.
 * All structural subtyping checks will be performed by static type checkers,
  such as ``mypy`` [mypy]_, no special support for protocol validation will
  be provided at runtime.


 Changes in typing module
 the corresponding runtime protocol counterpart.
 Practically, few changes will be needed in ``typing`` since some of these
 classes already behave the necessary way at runtime. Most of these will need
 to be updated only in the corresponding ``typeshed``stub.
 to be updated only in the corresponding ``typeshed``stubs [typeshed]_.

 All other concrete generic classes such as ``List``, ``Set``, ``IO``,
 ``Deque``, etc are sufficiently complex that it makes sense to keep
 Use assignments to check explicitly that a class implements a protocol
 ----------------------------------------------------------------------

 In Go language[golang]the explicit checks for implementation are performed
 via dummy assignments. Such way is also possible with the current proposal.
 Example::
 In Go language the explicit checks for implementation are performed
 via dummy assignments [golang]_. Such way is also possible with the current
 proposal.Example::

  class A:
      def __len__(self) -> float:
 .. [pep483]
   https://www.python.org/dev/peps/pep-0483/

 .. [pep526]
   https://www.python.org/dev/peps/pep-0526/

 .. [zope-interfaces]
   https://zopeinterface.readthedocs.io/en/latest/

 .. [golang]
   https://golang.org/doc/effective_go.html#interfaces_and_types

 .. [pep526]
   https://www.python.org/dev/peps/pep-0526/

 .. [typeshed]
   https://github.com/python/typeshed/
Original file line number	Diff line number	Diff line change
Expand Up		@@ -24,11 +24,11 @@ for structural subtyping (static duck typing).
		Rationale and Goals
		===================

		Currently, PEP 484 and ``typing`` module define abstract base classes for
		several common Python protocols such as ``Iterable`` and ``Sized``.
		The problem with them is that a class has to be explicitly marked to support
		them, which is arguably unpythonic and unlike what one would normally do in
		idiomatic dynamically typed Python code. For example,
		Currently, PEP 484[pep484]_and ``typing`` module[typing]_define abstract
		base classes forseveral common Python protocols such as ``Iterable`` and
		``Sized``.The problem with them is that a class has to be explicitly marked
		to supportthem, which is arguably unpythonic and unlike what one would
		normally do inidiomatic dynamically typed Python code. For example,
		this conforms to the PEP 484::

		from typing import Sized, Iterable, Iterator
Expand All		@@ -46,7 +46,7 @@ runtime costs. The intention of this PEP is to solve all these problems
		by allowing to write the above code without explicit base classes in
		the class definition, and ``Bucket`` would still be implicitly considered
		a subtype of both ``Sized`` and ``Iterable[int]`` by static type checkers
		using structural subtyping::
		using structural[wiki-structural-subtyping]_subtyping::

		from typing import Iterator

Expand All		@@ -71,13 +71,13 @@ Nominal vs structural subtyping
		The structural subtyping is natural for Python programmers since it matches
		the runtime semantics of duck typing: an object that has certain properties
		is treated independently of its actual runtime class.
		However, as discussed in PEP 483, both nominal and structural subtyping have
		their strengths and weaknesses. Therefore, in this PEPdo we not propose
		to replace the nominal subtyping described by PEP 484 with structural
		subtyping completely. Instead, it is proposed that the protocol classes
		complement normal classes, and the choice is left for a user to decide where
		to apply a particular solution. See section "Rejected ideas" for additional
		motivation.
		However, as discussed in PEP 483 [pep483]_, both nominal and structural
		subtyping havetheir strengths and weaknesses. Therefore, in this PEPwe
		do not proposeto replace the nominal subtyping described by PEP 484 with
		structuralsubtyping completely. Instead, it is proposed that the protocol
		classescomplement normal classes, and the choice is left for a user to decide
		whereto apply a particular solution. See section "Rejected ideas" for
		additionalmotivation.


		Non-Goals
Expand All		@@ -88,8 +88,8 @@ sophisticated runtime instance and class checks against protocol classes.
		This would be difficult and error-prone and will contradict the logic
		of PEP 484. As well, following PEP 484 and PEP 526 we state that protocols are
		completely optional and there is no intent to make them required.
		No runtime semantics will be imposed for variables or parameters annotated with
		a protocol class, the actual checks will be performed by third party type
		No runtime semantics will be imposed for variables or parameters annotated
		witha protocol class, the actual checks will be performed by third party type
		checkers and other tools.


Expand All		@@ -99,10 +99,10 @@ Existing approaches to structural subtyping
		Before describing the actual specification, we review existing approaches
		related to structural subtyping in Python and other languages:

		* Zope interfaces was one of the first widely used approaches to
		structural subtyping in Python. It is implemented by providing special
		classes to distinguish interface classes from normal classes, to mark
		interface attributes and to explicitly declare implementation.
		* Zope interfaces[zope-interfaces]_was one of the first widely used
		approaches tostructural subtyping in Python. It is implemented by providing
		specialclasses to distinguish interface classes from normal classes,
		to markinterface attributes and to explicitly declare implementation.
		For example::

		from zope.interface import Interface, Attribute, implements
Expand DownExpand Up		@@ -146,10 +146,10 @@ related to structural subtyping in Python and other languages:
		with a special base class is reasonable and easy to implement both
		statically and at runtime.

		* Python abstract base classes are the standard library tool to provide some
		functionality similar to structural subtyping. The drawback of this
		approach is the necessity to either subclass the abstract class or
		register an implementation explicitly::
		* Python abstract base classes[abstract-base-classes]_are the standard
		library tool to provide somefunctionality similar to structural subtyping.
		The drawback of thisapproach is the necessity to either subclass
		the abstract class orregister an implementation explicitly::

		from abc import ABCMeta

Expand All		@@ -165,9 +165,10 @@ related to structural subtyping in Python and other languages:
		static context. However, in runtime context, ABCs are good candidates for
		protocol classes and are already used extensively in ``typing`` module.

		* Abstract classes defined in ``collections.abc`` module are slightly more
		advanced since they implement a custom ``__subclasshook__()`` method that
		allows runtime structural checks without explicit registration::
		* Abstract classes defined in ``collections.abc`` module [collections-abc]_
		are slightly more advanced since they implement a custom
		``__subclasshook__()`` method that allows runtime structural checks without
		explicit registration::

		from collections.abc import Iterable

Expand All		@@ -185,9 +186,9 @@ related to structural subtyping in Python and other languages:
		that mimics the one in ``collections.abc``, see detailed specification
		below.

		* TypeScript provides support for user defined classes and interfaces.
		Explicit implementation declaration is not required, structural subtyping
		is verified statically. For example::
		* TypeScript[typescript]_provides support for user defined classes and
		interfaces.Explicit implementation declaration is not required,
		structural subtypingis verified statically. For example::

		interface LabelledItem {
		label: string;
Expand All		@@ -209,8 +210,8 @@ related to structural subtyping in Python and other languages:
		checking without runtime implications looks reasonable, and basically
		this proposal follows the same line.

		* Go uses a more radical approach and makes interfaces the primary way
		to provide type information. Also, assignments are used to explicitly
		* Go[golang]_uses a more radical approach and makes interfaces the primary
		wayto provide type information. Also, assignments are used to explicitly
		ensure implementation::

		type SomeInterface interface {
Expand DownExpand Up		@@ -341,7 +342,7 @@ that don't have an implementation. Such syntax mirrors how methods are
		defined in stub files. Abstract static methods, abstract class methods,
		and abstract properties are equally supported.

		To defined a protocol variable one should use the PEP 526 variable
		To defined a protocol variable one should use the PEP 526[pep526]_variable
		annotations in the class body. Attributes defined in the body of a method
		by assignment via ``self`` considered non-protocol members. The rationale for
		this is that the protocol class implementation is often not shared by
Expand DownExpand Up		@@ -757,6 +758,9 @@ effects on core interpreter and standard library except in
		from ``__annotations__`` to ``__subclsshook__()``.
		* In the backported version of ``typing``, translate ``...`` class attribute
		values to abstract properties.
		* All structural subtyping checks will be performed by static type checkers,
		such as ``mypy`` [mypy]_, no special support for protocol validation will
		be provided at runtime.


		Changes in typing module
Expand DownExpand Up		@@ -785,7 +789,7 @@ what are the methods these protocols implement, and immediately recognize
		the corresponding runtime protocol counterpart.
		Practically, few changes will be needed in ``typing`` since some of these
		classes already behave the necessary way at runtime. Most of these will need
		to be updated only in the corresponding ``typeshed``stub.
		to be updated only in the corresponding ``typeshed``stubs [typeshed]_.

		All other concrete generic classes such as ``List``, ``Set``, ``IO``,
		``Deque``, etc are sufficiently complex that it makes sense to keep
Expand DownExpand Up		@@ -873,9 +877,9 @@ complicate both the concept and the implementation.
		Use assignments to check explicitly that a class implements a protocol
		----------------------------------------------------------------------

		In Go language[golang]the explicit checks for implementation are performed
		via dummy assignments. Such way is also possible with the current proposal.
		Example::
		In Go language the explicit checks for implementation are performed
		via dummy assignments [golang]_. Such way is also possible with the current
		proposal.Example::

		class A:
		def __len__(self) -> float:
Expand DownExpand Up		@@ -909,9 +913,6 @@ References
		.. [pep483]
		https://www.python.org/dev/peps/pep-0483/

		.. [pep526]
		https://www.python.org/dev/peps/pep-0526/

		.. [zope-interfaces]
		https://zopeinterface.readthedocs.io/en/latest/

Expand All		@@ -927,6 +928,9 @@ References
		.. [golang]
		https://golang.org/doc/effective_go.html#interfaces_and_types

		.. [pep526]
		https://www.python.org/dev/peps/pep-0526/

		.. [typeshed]
		https://github.com/python/typeshed/

Expand Down