Support Python3.13

[Zeitsperre]

Pull Request Checklist:

• This PR addresses an already opened issue (for bug fixes / features)
  • This PR fixes Support for numpy 2.0 and Python 3.13 #2022
• Tests for the changes have been added (for bug fixes / features)
  • (If applicable) Documentation has been added / updated (for bug fixes / features)
• CHANGELOG.rst has been updated (with summary of main changes)
  • Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

• Adds a Python3.13 build to the CI
• Removes the sphinx-codeautolink/pygments workarounds
• Enforces ruff rule D213 (docstring titles start on second line)
• Adjusts docstring parsing logic for Python3.13 with backwards-compatibility

Does this PR introduce a breaking change?

No, but once this is passing, we should prepare to drop support for Python3.10. This is mentioned in CHANGELOG.rst.

Other information:

numba v0.61.0 was released earlier today: https://numba.readthedocs.io/en/stable/release/0.61.0-notes.html

[github-actions]

Note

It appears that this Pull Request modifies the main.yml workflow.

On inspection, the XCLIM_TESTDATA_BRANCH environment variable is set to the most recent tag (v2025.1.8).

No further action is required.

[Zeitsperre]

Will this trigger the advanced tests? Let's see.

It does. nice.

[Zeitsperre]

It looks as though there are changes to the ways that docstrings are parsed in Python3.13: https://docs.python.org/3.13/whatsnew/3.13.html#other-language-changes

This is breaking a lot of docstring tests. Will see what I can do.

Update: This looks like it's going to be complicated. Here's the PR that added the changes: python/cpython#81283

[aulemahal]

@Zeitsperre This commit pushed a very simple fix to the indentation issue. I have looked at docstring_parser and it might be a good alternative. The hypothesis is that it would be stronger. My doubt are because its a new dependency. And you know, these tend to break ;) . Also, I haven't taken the time to test it.

[Zeitsperre]

I have looked at docstring_parser and it might be a good alternative. The hypothesis is that it would be stronger. My doubt are because its a new dependency. And you know, these tend to break ;) . Also, I haven't taken the time to test it.

I'm not keen to add a new requirement (though maybe that library will find use elsewhere), even if it's a transitory one (until we no longer support Python3.12 and lower, so years, I suppose). If we can extract the parsing logic that we currently have to python version-dependent functions, we'll probably be much better off.

I'll see what I can do with your approach. Thanks!

[aulemahal]

The new code dedents the docstrings before parsing them, which assumes that all lines of the docstrings have a common indent. This is broken when multi-line docstrings start on the first line : this was the case in sdba.properties, which I fixed in the last commit.

In linting speak, this means we want to enforce rule D213 and not D212:

D212 	Multi-line docstring summary should start at the first line
D213 	Multi-line docstring summary should start at the second line

[Zeitsperre]

@aulemahal I think I've managed to clear up a few docstring issues (and some formatting errors that have been present for a long time, too!). The remaining warnings I'm seeing arise from the docstring for robustness_fractions:

We might need to revisit the logic of:

robustness_fractions.__doc__ = robustness_fractions.__doc__.format(
    tests_list="{" + ", ".join(list(SIGNIFICANCE_TESTS.keys()) + ["threshold"]) + "}",
    tests_doc="\n".join(map(_gen_test_entry, SIGNIFICANCE_TESTS.items()))[
        4:  # strip first 4 chars
    ],
)

[coveralls]

coverage: 89.973% (-0.001%) from 89.974%
when pulling 379b84f on support-python313
into 3152070 on main.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[Zeitsperre]

I'm reluctant to merge this until our documentation builds on Python3.13. The last issue is the parsing of docstrings needed for the robustness_fractions.

If I have time on Monday, I imagine the fix is quite simple (dedenting for all entries before constructing the section).