Deprecate setting the timer interval while starting it.

[anntzer]

This feature is unused internally and has simple replacements; removing it will make it easier for subclasses to directly override Timer.start (#26855) rather than having Timer.start handle the interval and then deferring to a private _timer_start.

PR summary

PR checklist

• "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

[ksunden]

Suggested change

	@_api.deprecate_parameter("3.9", "interval", alternative="timer.interval")
	@_api.delete_parameter("3.9", "interval", alternative="timer.interval")

[anntzer]

humpf yes.

[ksunden]

Needs to be added to the ci/mypy_stubtest_allowlist because the decorator changes the default value at runtime, so stubtest is not happy (but the current hint does reflect what users should see)

[anntzer]

If we cannot teach mypy about delete_parameter, would it be possible for the mypy-stubtest job to have some additional script that walks the source tree and auto-ignores anything decorated with delete_parameter?

Or perhaps much more simply, just something like inserting (approximately) grep -v _deprecated_parameter_class over the output of mypy-stubtest on CI so that we just drop all the invalid error messages about delete_parameter...

[ksunden]

Changing signatures with decorators can be done in some circumstances, though in particular editing keyword-only args is not doable currently...

Writing a script could be done, but it is rare enough that we haven't done it yet, and I think is likely more trouble than it's worth (really only affects parameter deletion, at least going forward, we have some deprecated APIs that never had stubs put in, but settled at "reflect implementation" for ongoing changes. rename/make_keyword_only are both adjusted to match the new signature and stubtest doesn't complain)

grep -v is problematic because the output is multi-line. Also I don't love ideas which make running locally harder than it already is (which admittedly does require passing in the allowlist...)
Also I think it checks the exit status for the top line pass/fail, and wrapping with grep would hide that. (We actually do a | sed on the meson branch, and have set -o pipefail so exit status is not a blocker there)

[anntzer]

I went for the grep (well, sed) based approach because I frankly don't like the idea of introducing additional churn to please mypy, but now CI is failing due to a token permission problem 🤷

[ksunden]

I think the permission thing is a red herring, this is actually the inverted logic of what I was originally worried about with grep occluding the exit status

The call still has exit status 1 because it found something, so it is failing the check.

[anntzer]

Thanks for pointing this out, I think I figured out a fix for that...

[ksunden]

I still object on the basis that running stubtest locally now fails, and that is something that I actually do.

I don't think the "churn" is that high, as it is one line in a dedicated file that only needs to be added and removed (with the deprecation cycle) for <5 items per release cycle (again, only parameter deletions, other deprecations do not need this).

[anntzer]

I still object on the basis that running stubtest locally now fails, and that is something that I actually do.

But running a bare mypy.stubtest already fails and you already need to have some magical invocation (setting MPLBACKEND to agg and filtering out the allowlist) to make it work; this PR simply makes the magical invocation slightly longer.

I don't think the "churn" is that high, as it is one line in a dedicated file that only needs to be added and removed

I object on the basis that typing should be helping devs (well, if it can...), not making life any harder for them. I can accept some additional work, but absolutely not when mypy is just not flexible enough and its limitations need to be worked around.

[ksunden]

I've opened #26928, which implements the script version of this idea so that exit status is still valid, but does not require manual editing for new deprecations.

This also helps with the "stubtest requires arcane parameters" as now it can be run as python tools/stubtest.py, all of the parameters are included in the script instead.

I still would argue that claiming mypy is unable to work around it is slightly unfair, as the allow list is the mechanism provided to work around it. We are doing dynamic changes to signatures, which is somewhat antithetical to static checking. mypy itself is actually fine with it (it just doesn't see the changed signature), it is the fact that we are doing additional checks which look at runtime behavior that this comes into play.

That said, I had been thinking of putting something in tools for running it to make it easier, though may have gone with a simpler shell script. but this turned out to not be so hard (hardest part was getting the fully qualified names out of the AST)

[anntzer]

Thanks for taking my complaints into account :)