Deprecate attributes and expire deprecation in animation - #24131

I do not understand the warnings:

/home/circleci/project/doc/api/_as_gen/matplotlib.animation.ArtistAnimation.rst:33:<autosummary>:1: WARNING: py:obj reference target not found: matplotlib.animation.ArtistAnimation.repeat
/home/circleci/project/lib/matplotlib/animation.py:docstring of matplotlib.animation.FuncAnimation.new_frame_seq:1:<autosummary>:1: WARNING: py:obj reference target not found: matplotlib.animation.FuncAnimation.repeat

These are "new" attributes, in the sense that they are defined in the class rather than in __init__, but only for the purpose of being deprecated. And the save_count attribute does not behave like that. As far as I can tell, none in referenced explicitly, so should be some sort of autodoc thing.

(I know that I've had similar issues with attributes earlier though...)

I don't think save_count=None was the intended removal, the default of 100 was; see #8278.

Yeah, you are right. Forgot about the purpose a bit in...

It seems like other parts of the code are relying on save_count being an integer (either provided or computed). So the behaviour discussed in #8278 is not straightforward to obain (which may be the reason it not has been removed since 2.2...).

I guess that one can protect the line

self._save_seq = self._save_seq[-self._save_count:]

with a None-check though...

Um what happens in the infinite case if there's no trim?

Then I think @anntzer has argued that it keeps running unless you specify save_count, just as it does with infinite generators elsewhere.

Then I think @anntzer has argued that it keeps running unless you specify save_count, just as it does with infinite generators elsewhere.

how do you save an infinitely running movie?

how do you save an infinitely running movie?

I guess that there is a file size limit:

Animation size has reached 21248815 bytes, exceeding the limit of 20971520.0. If you're sure you want a larger animation embedded, set the animation.embed_limit rc parameter to a larger value (in MB). This and further frames will be dropped.

@story645 is correct that there is an unbounded cache in the case of an inifinte generator that needs to be addressed. The cap on the file size is also only in the jshtml export logic (so we do not make a multi-gigabyte html page 🤣, related if you want to see your browser break build our docs as singlehtml, but I digress).

I pushed some commits that protect against this. There might need to be some more thought around the default value of cache_data_frames as well. I think this is going to hard break some use-cases, but those cases should also have been getting user visible warnings from 2.2 (which is 7 mpl versions).

Also working on the rebase and will add some tests.

and we are leaving the footcannon of trying to save an infinite generator, we just won't cache the data along the way. I think we have to leave this as it is unlikely we will be able to solve the halting problem.

I've tried to squash locally, but it just gets messed up. Please squash on merge...

Feels like I've lost track of this, but I think that everything is considered now. The cleanliness may not be correct (in that case it is added yet again, since it is there).

So please squash upon merge... :-)

I've tried to squash locally, but it just gets messed up. Please squash on merge...

You should be able to reset to a point you want to be at, including your remote, and then start cleaning up.

git reset --hard origin/animationdeprecations
git rebase -i upstream/main
# clean up
git push --force-with-lease

I'm working on sorting out what is going on with the history here.

I think what happened is I had rebased and force-pushed, then Oscar merged that back into his branch and then added some more changes on top.

I started from just before the merge and then cherry-picked the exrta commits on top and force-pushed again.

Yes, there was a bit of a hassle with commits, especially since I've been using two different computers. Have to learn how to deal with that in a better way...

(The main "issue" is that there will be a lot of intermediate conflicts while rebasing although the final diff will not have any conflicts...)

Just need to sort out the doc failure then. (And possibly use privatize_attribute? I seem to recall that it was used at some stage...)

Tried to fix the doc-failure by updating missing references. Seems to make sense since this became a problem for a deprecated attribute that will go away soon anyway. (And it removes a few hundred lines from this file.)

(The main "issue" is that there will be a lot of intermediate conflicts while rebasing although the final diff will not have any conflicts...)

One trick I use (particuarly if I do not super care about the history or am willing to re-create it later) is to squash everything to one commit and then rebase.