Modernize developer-guide pages for third-party tools

claude · Carreau · commit fe6c82644f93 · 2026-07-05T15:18:13.000+02:00
how_ipython_works.rst: - Terminal IPython has done tab completion with prompt_toolkit, not readline, since 5.0. - Point octave_kernel/bash_kernel at pypi.org (pypi.python.org was retired in 2018) and zeromq.org at https. wrapperkernels.rst: - Fix the 'cusor_pos' typo in the do_complete/do_inspect signatures. - Link the messaging spec directly to the jupyter_client docs instead of bouncing through the local two-line orphan stub. - Python 3's input(), not raw_input(); https Octave link; Oct2Py docs moved from the retired blink1073.github.io page to Read the Docs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017opRcTs1YU21naKjRQrzs4
diff --git a/docs/source/development/how_ipython_works.rst b/docs/source/development/how_ipython_works.rst
@@ -12,7 +12,8 @@ the terminal. It does something like this::
         exec(code)
 
 Of course, it's much more complex, because it has to deal with multi-line
-code, tab completion using :mod:`readline`, magic commands, and so on. But the
+code, tab completion using `prompt_toolkit
+<https://python-prompt-toolkit.readthedocs.io/>`__, magic commands, and so on. But the
 model is like that: prompt the user for some code, and when they've entered it,
 exec it in the same process. This model is often called a REPL, or
 Read-Eval-Print-Loop.
@@ -24,7 +25,7 @@ All the other interfaces—the Notebook, the Qt console, ``jupyter console`` in
 the terminal, and third party interfaces—use the IPython Kernel. This is a
 separate process which is responsible for running user code, and things like
 computing possible completions. Frontends communicate with it using JSON
-messages sent over `ZeroMQ <http://zeromq.org/>`_ sockets; the protocol they use is described in
+messages sent over `ZeroMQ <https://zeromq.org/>`_ sockets; the protocol they use is described in
 :ref:`jupyterclient:messaging`.
 
 The core execution machinery for the kernel is shared with terminal IPython:
@@ -49,9 +50,9 @@ the target language:
 .. image:: figs/other_kernels.png
 
 Wrapper kernels are easier to write quickly for languages that have good Python
-wrappers, like `octave_kernel <https://pypi.python.org/pypi/octave_kernel>`_, or
+wrappers, like `octave_kernel <https://pypi.org/project/octave_kernel/>`_, or
 languages where it's impractical to implement the communications machinery, like
-`bash_kernel <https://pypi.python.org/pypi/bash_kernel>`_. Native kernels are
+`bash_kernel <https://pypi.org/project/bash_kernel/>`_. Native kernels are
 likely to be better maintained by the community using them, like
 `IJulia <https://github.com/JuliaLang/IJulia.jl>`_ or `IHaskell <https://github.com/gibiansky/IHaskell>`_.
 
diff --git a/docs/source/development/wrapperkernels.rst b/docs/source/development/wrapperkernels.rst
@@ -5,8 +5,8 @@ Making simple Python wrapper kernels
 
 You can now re-use the kernel machinery in IPython to easily make new kernels.
 This is useful for languages that have Python bindings, such as `Octave
-<http://www.gnu.org/software/octave/>`_ (via
-`Oct2Py <http://blink1073.github.io/oct2py/>`_), or languages
+<https://www.gnu.org/software/octave/>`_ (via
+`Oct2Py <https://oct2py.readthedocs.io/>`_), or languages
 where the REPL can be controlled in a tty using `pexpect <https://pexpect.readthedocs.io/en/latest/>`_,
 such as bash.
 
@@ -57,12 +57,13 @@ following methods and attributes:
      :param dict user_expressions: Mapping of names to expressions to evaluate
          after the code has run. You can ignore this if you need to.
      :param bool allow_stdin: Whether the frontend can provide input on request
-         (e.g. for Python's :func:`raw_input`).
+         (e.g. for Python's :func:`input`).
      
      Your method should return a dict containing the fields described in
      :ref:`execution_results`. To display output, it can send messages
      using :meth:`~ipykernel.kernelbase.Kernel.send_response`.
-     See :doc:`messaging` for details of the different message types.
+     See :ref:`jupyterclient:messaging` for details of the different message
+     types.
 
 To launch your kernel, add this at the end of your module::
 
@@ -114,11 +115,11 @@ Optional steps
 
 You can override a number of other methods to improve the functionality of your
 kernel. All of these methods should return a dictionary as described in the
-relevant section of the :doc:`messaging spec <messaging>`.
+relevant section of the :ref:`messaging spec <jupyterclient:messaging>`.
 
 .. class:: MyBetterKernel
 
-   .. method:: do_complete(code, cusor_pos)
+   .. method:: do_complete(code, cursor_pos)
 
      Code completion
      
@@ -129,7 +130,7 @@ relevant section of the :doc:`messaging spec <messaging>`.
      
         :ref:`msging_completion` messages
 
-   .. method:: do_inspect(code, cusor_pos, detail_level=0)
+   .. method:: do_inspect(code, cursor_pos, detail_level=0)
 
      Object introspection
      
