Add proposed resolution to most open issues.

Author: Guido van Rossum

README.rst

@@ -26,58 +26,72 @@ Work in progress notes
   precedent in ``abc``, namely ``Callable``, and ``Hashable``.
   However, attempts at implementing reasonable runtime behavior
   suggests that it may be better to leave ``collections.abc`` alone.
+  **Proposed resolution: leave ``collections.abc`` alone.**
 
 * ``Var('T')`` is put in ``collections.abc`` as a helper with generics
   and covariance/contravariance in ABCs.  May be renamed to ``TypeVar``.
   The co-/contravariance behavior requires more thinking.
+  **Proposed resolution: Use ``TypeVar``, with mypy's semantics mapped:
+  ``typevar('T', values=(str, bytes)`` becomes ``TypeVar('T', str, bytes)``.**
 
 * ``AnyStr`` (and consequently ``IO``) smells like basestring in
   disguise, what is the use case for Python 3?  Answer: There are
   lots of things in the stdlib that are essentially overloaded as
   str-in-str-out and bytes-in-bytes-out; ``AnyStr`` has exactly the
   right behavior for this (unlike ``Union[str, bytes]``).
+  **Proposed resolution: keep ``AnyStr``, ``IO`` and its subclasses,
+  in typing.py.**
 
-* ``Undefined`` smells like JavaScript, I left it out for now.
+* ``Undefined`` smells like JavaScript, I (Łukasz) left it out for now.
   However, mypy needs it.  See https://github.com/ambv/typehinting/issues/20
+  **Help???**
 
 * The addition of ``Match`` and ``Pattern`` seems arbitrary and should
   rather be fixed in ``re`` directly, with the types just imported in
   ``typing``. If so, are there any other potentially useful types we'd
   like?  See https://github.com/ambv/typehinting/issues/23
+  **Proposed resolution: keep these two in typing.py for convenience.**
 
-* I left out ``overload`` because I don't understand its purpose. If we
+* I (Łukasz) left out ``overload`` because I don't understand its purpose. If we
   need generic dispatch, we should add it to ``functools``.
   Perhaps ``overload`` should only be allowed in stub modules?
   See https://github.com/ambv/typehinting/issues/14
+  **Proposed resolution: support the syntax but only in stub files.**
 
-* I left out specifying protocols as they are an ABC implementation
+* I (Łukasz) left out specifying protocols as they are an ABC implementation
   detail from the perspective of this PEP. However, they should be
   defined in a separate PEP because making ``__subclasshook__`` less
   dynamic when possible (which is often) would make ABCs much better
   behaved in static analysis contexts.
   See https://github.com/ambv/typehinting/issues/11
+  **Help???**
 
 * Having the last thing in mind, ``IO``, ``BinaryIO`` and ``TextIO``
   would simply be new abstract base classes, usable with or without type
-  hinting
+  hinting.
+  **Proposed resolution: ``IO`` is generic over ``AnyStr``, the other two
+  are concrete (subclassing ``IO[bytes]`` and ``IO[str]`` respectively).**
 
-* the current implementation of ``*IO`` is quite un-ducktyped (specifies
+* The current implementation of ``*IO`` is quite un-ducktyped (specifies
   both reading and writing as one protocol)
+  **Help???**
 
-* I left out ``cast`` because it can be more consistently expressed as::
+* I (Łukasz) left out ``cast`` because it can be more consistently expressed as::
 
     bad_typed_list = [1, 2, 3]        # type: list
     ...
     well_typed_list = bad_typed_list  # type: List[int]
 
   See https://github.com/ambv/typehinting/issues/15
+  **Proposed resolution: add ``cast(type, value)`` back in.**
 
-* I removed ``mypy`` from the listed "existing approaches" since we
-  basically describe what mypy is
+* I (Łukasz) removed ``mypy`` from the listed "existing approaches" since we
+  basically describe what mypy is.  **Proposed resolution: fine.**
 
-* I thought if introducing optional contravariance/invariance to ``Var``
+* I (Łukasz) thought if introducing optional contravariance/invariance to ``Var``
   has merit but I'm undecided; definitely complicates the type checker.
   See https://github.com/ambv/typehinting/issues/2
+  **Help???**
 
 
 Changes to MyPy coming from this proposal
@@ -90,10 +104,12 @@ Changes to MyPy coming from this proposal
   https://github.com/JukkaL/mypy/issues/539 and
   https://github.com/ambv/typehinting/issues/1 and
   https://github.com/ambv/typehinting/issues/2 and maybe others.
-  
+  **Proposed resolution: ``TypeVar`` (see above).**  
 
 * ``Union`` behaves differently, it holds the defined types in order
   to be able to actually respond to issubclass.
+  **Proposed resolution: This doesn't affect mypy; I do want this for
+  typing.py (also for generic types).**
 
 * ``typing.Function`` becomes ``typing.Callable``, which is equivalent
   to ``collections.abc.Callable``.  (Has now been implemented in mypy.)
@@ -108,23 +124,29 @@ Open issues
 * State of the art: should we list decorator-based approaches
   (PyContracts?) and docstring-based approaches?
 
-* should we recommend the use of ABCs over builtin types when possible?
+* Should we recommend the use of ABCs over builtin types when possible?
 
-* should we provide type shortcuts so that MutableMapping is not 3.5x
+* Should we provide type shortcuts so that MutableMapping is not 3.5x
   longer to type than dict?
 
-* is multiple dispatch using type hints in scope for this PEP?
+* Is multiple dispatch using type hints in scope for this PEP?
+  **Proposed resolution: let's wait, allow @overload only in stubs.**
 
-* should we mention platform- or version-specific typing? Guido mentioned
+* Should we mention platform- or version-specific typing? Guido mentioned
   Windows vs. POSIX during the Skype meeting.
+  **Proposed resolution: let typing.py export a few specific constants;
+  PY3, PY2, PY3_x (for x in 2, 3, 4, 5).**
 
-* it would be useful to have a ``Subclass[]`` factory that would be
+* It would be useful to have a ``Subclass[]`` factory that would be
   equivalent to "any class that has the all the following classes in its
   MRO".  Maybe we'd want to rename union to ``Any[]`` and this new
   proposed type to ``All[]``?  See https://github.com/ambv/typehinting/issues/18
+  **Proposed resolution: let's just have ``Union[T1, T2, ...]`` and ``Any``.**
 
 * Callable signature definition should be explained and support all
-  valid function signatures
+  valid function signatures.
+  **Proposed resolution: ``Callable[[T1, T2, ...], Tr]``.**
 
 * What about all other collections available in the ``collections``
   module?
+  **Proposed resolution: make Generic types retain their argument type(s).**