Doc fixes

2 files changed, 21 insertions, 23 deletions

diff --git a/CHANGES.md b/CHANGES.md
index 89ca8eb..f37ee53 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -3,7 +3,8 @@ HISTORY
 
 ## unreleased
 
-Ported CI from Travis to GitHub
+Dropped support for Python < 3.5 with a substantial simplification of
+the code base. Ported CI from Travis to GitHub.
 
 ## 4.4.2 (2020-02-29)
 
diff --git a/src/tests/documentation.py b/src/tests/documentation.py
index 6a11b5c..b827c1a 100644
--- a/src/tests/documentation.py
+++ b/src/tests/documentation.py
@@ -17,7 +17,7 @@ doc = r"""Decorators for Humans
 |---|---|
 |E-mail | michele.simionato@gmail.com|
 |Version| $VERSION ($DATE)|
-|Supports| Python 2.6, 2.7, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8|
+|Supports| Python 3.5, 3.6, 3.7, 3.8, 3.9|
 |Download page| http://pypi.python.org/pypi/decorator/$VERSION|
 |Installation| ``pip install decorator``|
 |License | BSD license|
@@ -27,22 +27,12 @@ Introduction
 
 The ``decorator`` module is over ten years old, but still alive and
 kicking. It is used by several frameworks (IPython, scipy, authkit,
-pylons, pycuda, sugar, ...) and has been stable for a *long*
-time. It is your best option if you want to preserve the signature of
-decorated functions in a consistent way across Python
-releases. Version 4 is fully compatible with the past, except for
-one thing: support for Python 2.4 and 2.5 has been dropped. That
-decision made it possible to use a single code base both for Python
-2.X and Python 3.X. This is a *huge* bonus, since I could remove over
-2,000 lines of duplicated documentation/doctests. Having to maintain
-separate docs for Python 2 and Python 3 effectively stopped any
-development on the module for several years. Moreover, it is now
-trivial to distribute the module as an universal
- [wheel](http://pythonwheels.com) since 2to3 is no more
-required. Since Python 2.5 has been released ages ago (in 2006), I felt that
-it was reasonable to drop the support for it. If you need to support
-ancient versions of Python, stick with the decorator module version
-3.4.2.  The current version supports all Python releases from 2.6 up.
+pylons, pycuda, sugar, ...) and has been stable for a *long* time. It
+is your best option if you want to preserve the signature of decorated
+functions in a consistent way across Python releases. Version 5.X
+requires Python versions greater than 3.4, but you can support back to
+Python 2.6 by using version 4.X and version 3.X is able to support
+even Python 2.4 and 2.5.
 
 What's New in version 4
 -----------------------
@@ -1292,11 +1282,18 @@ notice that lately I have come to believe that decorating functions with
 keyword arguments is not such a good idea, and you may want not to do
 that.
 
-On a similar note, for old versions of the decorator module (< 4.5)
-there is a restriction on argument names. For instance,
-if you have an argument called ``_call_`` or ``_func_``, you will get a
-``NameError`` when decorating the function. This restriction has been
-lifted in version 4.5.
+On a similar note, there is a restriction on argument names. For instance,
+if you name an argument ``_call_`` or ``_func_``, you will get a ``NameError``:
+
+```python
+>>> @trace
+... def f(_func_): print(f)
+...
+Traceback (most recent call last):
+  ...
+NameError: _func_ is overridden in
+def f(_func_):
+    return _call_(_func_, _func_)
 
 Finally, the implementation is such that the decorated function makes
 a (shallow) copy of the original function dictionary: