On Python 3.9, we cannot longer avoid using collections.abc

Related to https://github.com/micheles/decorator/issues/75#issuecomment-570827328

1 files changed, 18 insertions, 17 deletions

diff --git a/docs/documentation.md b/docs/documentation.md
index 7ff010a..53196e4 100644
--- a/docs/documentation.md
+++ b/docs/documentation.md
@@ -1303,15 +1303,16 @@ Consider this class:
 ```
 
 This class defines a ``__len__`` method, and is therefore
-considered to be a subclass of the abstract base class ``collections.Sized``:
+considered to be a subclass of the abstract base class
+``collections.abc.Sized`` (``collections.Sized`` on Python 2):
 
 ```python
->>> issubclass(WithLength, collections.Sized)
+>>> issubclass(WithLength, collections.abc.Sized)
 True
 
 ```
 
-However, ``collections.Sized`` is not in the MRO_ of ``WithLength``; it
+However, ``collections.abc.Sized`` is not in the MRO_ of ``WithLength``; it
 is not a true ancestor. Any implementation of generic functions (even
 with single dispatch) must go through some contorsion to take into
 account the virtual ancestors.
@@ -1329,7 +1330,7 @@ In particular, if we define a generic function...
 
 ```python
 
- @get_length.register(collections.Sized)
+ @get_length.register(collections.abc.Sized)
  def get_length_sized(obj):
      return len(obj)
 ```
@@ -1342,7 +1343,7 @@ In particular, if we define a generic function...
 
 ```
 
-...even if ``collections.Sized`` is not a true ancestor of ``WithLength``.
+...even if ``collections.abc.Sized`` is not a true ancestor of ``WithLength``.
 
 Of course, this is a contrived example--you could just use the
 builtin ``len``--but you should get the idea.
@@ -1357,7 +1358,7 @@ the following:
 
 ```python
 
- class SomeSet(collections.Sized):
+ class SomeSet(collections.abc.Sized):
      # methods that make SomeSet set-like
      # not shown ...
      def __len__(self):
@@ -1365,14 +1366,14 @@ the following:
 ```
 
 Here, the author of ``SomeSet`` made a mistake by inheriting from
-``collections.Sized`` (instead of ``collections.Set``).
+``collections.abc.Sized`` (instead of ``collections.abc.Set``).
 
 This is not a problem. You can register *a posteriori*
-``collections.Set`` as a virtual ancestor of ``SomeSet``:
+``collections.abc.Set`` as a virtual ancestor of ``SomeSet``:
 
 ```python
->>> _ = collections.Set.register(SomeSet)
->>> issubclass(SomeSet, collections.Set)
+>>> _ = collections.abc.Set.register(SomeSet)
+>>> issubclass(SomeSet, collections.abc.Set)
 True
 
 ```
@@ -1381,7 +1382,7 @@ Now, let's define an implementation of ``get_length`` specific to set:
 
 ```python
 
- @get_length.register(collections.Set)
+ @get_length.register(collections.abc.Set)
  def get_length_set(obj):
      return 1
 ```
@@ -1397,10 +1398,10 @@ the class registry, so it uses the more specific implementation for ``Set``:
 ```
 
 Sometimes it is not clear how to dispatch. For instance, consider a
-class ``C`` registered both as ``collections.Iterable`` and
-``collections.Sized``, and defines a generic function ``g`` with
-implementations for both ``collections.Iterable`` *and*
-``collections.Sized``:
+class ``C`` registered both as ``collections.abc.Iterable`` and
+``collections.abc.Sized``, and defines a generic function ``g`` with
+implementations for both ``collections.abc.Iterable`` *and*
+``collections.abc.Sized``:
 
 ```python
 
@@ -1411,11 +1412,11 @@ implementations for both ``collections.Iterable`` *and*
      def g(obj):
          raise NotImplementedError(type(g))
  
-     @g.register(collections.Sized)
+     @g.register(collections.abc.Sized)
      def g_sized(object):
          return "sized"
  
-     @g.register(collections.Iterable)
+     @g.register(collections.abc.Iterable)
      def g_iterable(object):
          return "iterable"