Update README to reflect retirement of Python 3.5 and earlier.

README.rst

@@ -63,6 +63,8 @@ based on ``path``.
 Advantages
 ==========
 
+Path pie provides a superior experience to similar offerings.
+
 Python 3.4 introduced
 `pathlib <https://docs.python.org/3/library/pathlib.html>`_,
 which shares many characteristics with ``path``. In particular,
@@ -75,26 +77,29 @@ has several advantages over ``pathlib``:
 - ``path`` implements ``Path`` objects as a subclass of ``str``, and as a
   result these ``Path`` objects may be passed directly to other APIs that
   expect simple text representations of paths, whereas with ``pathlib``, one
-  must first cast values to strings before passing them to APIs unaware of
-  ``pathlib``. This shortcoming was somewhat `mitigated by PEP 519
-  <https://www.python.org/dev/peps/pep-0519/>`_, in Python 3.6.
+  must first cast values to strings before passing them to APIs that do
+  not honor `PEP 519 <https://www.python.org/dev/peps/pep-0519/>`_
+  ``PathLike`` interface.
 - ``path`` give quality of life features beyond exposing basic functionality
   of a path. ``path`` provides methods like ``rmtree`` (from shlib) and
   ``remove_p`` (remove a file if it exists), properties like ``.permissions``,
   and sophisticated ``walk``, ``TempDir``, and ``chmod`` behaviors.
 - As a PyPI-hosted package, ``path`` is free to iterate
   faster than a stdlib package. Contributions are welcome
   and encouraged.
-- ``path`` provides a uniform abstraction over its Path object,
+- ``path`` provides superior portability using a uniform abstraction
+  over its single Path object,
   freeing the implementer to subclass it readily. One cannot
   subclass a ``pathlib.Path`` to add functionality, but must
   subclass ``Path``, ``PosixPath``, and ``WindowsPath``, even
-  if one only wishes to add a ``__dict__`` to the subclass
+  to do something as simple as to add a ``__dict__`` to the subclass
   instances.  ``path`` instead allows the ``Path.module``
   object to be overridden by subclasses, defaulting to the
   ``os.path``. Even advanced uses of ``path.Path`` that
   subclass the model do not need to be concerned with
-  OS-specific nuances.
+  OS-specific nuances. ``path.Path`` objects are inherently "pure",
+  not requiring the author to distinguish between pure and non-pure
+  variants.
 
 This path project has the explicit aim to provide compatibility
 with ``pathlib`` objects where possible, such that a ``path.Path``