Fix links

python-attrs · Oct 15, 2019 · eec7e43 · eec7e43
1 parent 6d2f127
commit eec7e43
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 2 deletions.
diff --git a/.github/CONTRIBUTING.rst b/.github/CONTRIBUTING.rst
@@ -245,6 +245,6 @@ Thank you for considering contributing to ``attrs``!
 .. _`team of volunteers`: https://github.com/python-attrs
 .. _BDFL: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
 .. _towncrier: https://pypi.org/project/towncrier
-.. _black: https://github.com/ambv/black
+.. _black: https://github.com/psf/black
 .. _pre-commit: https://pre-commit.com/
 .. _isort: https://github.com/timothycrosley/isort
diff --git a/docs/why.rst b/docs/why.rst
@@ -102,7 +102,7 @@ Other often surprising behaviors include:
   you end up with a class that has *two* ``Point``\ s in its :attr:`__mro__ <class.__mro__>`: ``[<class 'point.Point'>, <class 'point.Point'>, <type 'tuple'>, <type 'object'>]``.
 
   That's not only confusing, it also has very practical consequences:
-  for example if you create documentation that includes class hierarchies like `Sphinx's autodoc <http://www.sphinx-doc.org/en/stable/ext/autodoc.html>`_ with ``show-inheritance``.
+  for example if you create documentation that includes class hierarchies like `Sphinx's autodoc <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html>`_ with ``show-inheritance``.
   Again: common problem, hacky solution with confusing fallout.
 
 All these things make ``namedtuple``\ s a particularly poor choice for public APIs because all your objects are irrevocably tainted.