Add some examples

python · gvanrossum · Mar 18, 2017 · Mar 5, 2017 · Mar 5, 2017 · Mar 5, 2017
commit 993f7b3d716ab569a778881813353efb8b371980
diff --git a/pep-05xx.txt b/pep-05xx.txt
@@ -16,7 +16,11 @@ Python-Version: 3.7
 Abstract
 ========
 
-This PEP describes the static and runtime behavior of protocol classes.
+PEP 484 has introduced type hints that can be used to specify type metadata
+for static type checkers and other third party tools. However, PEP 484
+only supports the *nominal* subtyping. In this PEP we specify the static
+and runtime semantics of protocol classes that will provide a support for
+*structural* subtyping (static duck typing).
 
 
 Rationale and Goals
@@ -48,24 +52,87 @@ still be implicitly considered a subtype of both ``Sized`` and
       def __iter__(self) -> Iterator[int]: ...
 
 
+Nominal vs structural subtyping
+-------------------------------
+
+As discussed in PEP 483, both nominal and structural subtyping have their
+strengths and weaknesses. Therefore, in this PEP do we not propose to propose
+to replace the nominal subtyping described by PEP 484 and currently supported
+by the ``typing`` module. 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.
+
+
 Non-Goals
 ---------
 
 Runtime protocol classes are simple ABCs. Moreover as PEP 484 and PEP 526
 stated they are **completely optional**.
 
 
-Nominal vs structural subtyping
-===============================
-
-
 Existing approaches to structural subtyping
 ===========================================
 
-* ``zope.interace``
-* TypeScript
+* ``zope.interace``::
+
+  from zope.interface import Interface
+  from zope.interface import Attribute
+  from zope.interface import implements
+
+  class IHost(Interface):
+      """A host object"""
+
+      name = Attribute("Name of host")
+
+      def goodmorning(guest):
+          """Say good morning to guest"""
+
+  class Host(object):
+
+      implements(IHost)
+
+      name = u''
+
+      def goodmorning(self, guest):
+          return "Good morning, %s!" % guest
+
+plus much more detailed runtime constraints::
+
+  from zope.interface import invariant
+
+  def contacts_invariant(obj):
+      if not (obj.email or obj.phone):
+          raise Exception("At least one contact info is required")
+
+  class IPerson(Interface):
+
+      name = Attribute("Name")
+      email = Attribute("Email Address")
+      phone = Attribute("Phone Number")
+
+      invariant(contacts_invariant)
+
+However, this all requires runtime validation.
+
+* TypeScript::
+
+  interface LabelledValue {
+      label: string;
+  }
+
+  function printLabel(labelledObj: LabelledValue) {
+      console.log(labelledObj.label);
+  }
+
+  let myObj = {size: 10, label: "Size 10 Object"};
+  printLabel(myObj);
+
 * Go - everything is an interface
 * ABCs
+
+require explicit subclassing or registration.
+
 * ``collections.abc`` (with ``__subclasshook__``)
 
 
@@ -270,6 +337,8 @@ provide a default implementation that could be used in explicit subclasses.
 
 Overall, I'm probably the least happy about this part of the proposal.
 
+"Private" variables on self? treat (double?) underscores as private?
+
 
 Explicitly declaring implementation
 -----------------------------------
@@ -411,6 +480,8 @@ We need this fallback option anyway for backward compatibility.
 
 ``Type[...]`` accepts only non-abstract (non-protocol?) classes
 
+copy all stuff from my PR
+
 
 Runtime behavior of protocol classes
 ====================================