Fix many py2-style prints in docs and commented code. (#14432)
The main interest was to transform py2-style print statements that still
appeared in some docstrings (e.g. for %history) and would thus show up
when looking at the docs either interactively or in the rendered
website. I also fixed a number of commented-out print statements at the
same time, mostly because it was easier for me to just regexp-change all
of them so that I could focus on the others.
Display Greek small letter mu (#14426)
`%time foo()` output is often copied into code comments to explain
performance improvements. The `\xb5` Latin Extended micro sign and the
`\u03bc` Greek small letter mu have different codes but often look
identical.
Output mu to align with:
* [The International System of Units (SI) brochure](
https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf
), such as Table 7 SI prefixes
* NFKC normalized [Python code](https://peps.python.org/pep-3131/
) and [domain names](https://unicode.org/reports/tr36/). For example:
```sh
python -c 'print("""class C:
\xb5=1
print(hex(ord(dir(C)[-1])))""")' | tee /dev/fd/2 | python -
```
```python
class C:
µ=1
print(hex(ord(dir(C)[-1])))
```
`0x3bc`
* Section 2.5 Duplicated Characters of [Unicode Technical Report 25](
https://www.unicode.org/reports/tr25/)
> ...U+03BC μ is the preferred character in a Unicode context.
* Ruff confusable mapping [updates](
https://github.com/astral-sh/ruff/pull/4430/files
), currently in the "preview" stage
Add a unit test for UTF-8 display and
https://bugs.launchpad.net/ipython/+bug/348466 ASCII fallback.
Update Matplotlib docs (#14425)
This updates the docs in line with the recent changes to move Matplotlib
backend resolution to Matplotlib itself. In passing I have removed
references to things that have definitely disappeared from Matplotlib
(such as `qt4`), and I've added a comment about when
`_matplotlib_manages_backends()` can be removed in future.
This, along with #14420, should conclude the backend transition.
Fix many py2-style prints in docs and commented code.
The main interest was to transform py2-style print statements that still
appeared in some docstrings (e.g. for %history) and would thus show up
when looking at the docs either interactively or in the rendered
website. I also fixed a number of commented-out print statements at the
same time, mostly because it was easier for me to just regexp-change all
of them so that I could focus on the others.
Fix downstream ipykernel tests (#14424)
Locally I can get the downstream `ipykernel` tests to pass just by
removing the explicit downgrade of `pytest` and `pytest_asyncio`, so
here trying it in CI.
Fix listing of subcommands for "ipython profile" and "ipython history". (#14421)
The previous code (likely going back to Py2) would print
Must specify one of: dict_keys(['create', 'list', 'locate'])
This PR fixes it to
Must specify one of: 'create', 'list', 'locate'.
Convert "osx" gui framework to/from "macosx" in Matplotlib (#14420)
This is a correction to the code that moves backend handling to
Matplotlib, which came to light during the review of
matplotlib/matplotlib#27948. The GUI framework of macOSX is called `osx`
in IPython but `macosx` in Matplotlib.
It would be possible to allow passing a GUI framework of `osx` to
Matplotlib and internally converting it to `macosx`, but the reverse
direction is problematic as we would like the answer to be `osx` if we
are using IPython and `macosx` if using pure Matplotlib. Therefore the
simplest solution is to do the translation in IPython. It is not ideal
as we want to minimise such Matplotlib-related implementation details in
IPython, but the changes here are small and simple and hence I think
they are acceptable.
There are two new private functions `_convert_gui_to_matplotlib` and
`_convert_gui_from_matplotlib` to do the required checking and
conversion, and these are called whenever a GUI framework name is passed
to or from Matplotlib. There are only 3 places in the code where this is
currently required.
Inevitably this comes to light just after the release of IPython 8.24.0!
But it is not a problem for end users until the next Matplotlib release
which contains matplotlib/matplotlib#27948. If that occurs really
quickly (sometime in May?) perhaps we could release an IPython 8.24.1
just beforehand, otherwise the usual planned release at the end of next
month would be fine.
M Bussonnier
Antony Lee