@anntzer Can you further detail your concerns? Right now, the entire purpose ofImageMagickWriter is essentially to "[reproduce] the imagemagick command line as kwargs". I mean it does it in an abstracted form so that users don't need to know esoteric details like-layers OptimizePlus, they just know the much more readily googl-able and readablecompress=True.

Thanks for the feedback. I agree with@anntzer, in that reproducing common args from a utility as args in python does seem like a code smell.

I would be fully on board with making compression the de-facto behavior. I personally initially presumed that matplotlib's use of ImageMagick would do the obvious method of reducing file size by not making each frame of the .gif full-sized.

Doing the above, I'd be tempted to allow the end-user to disable with ano_compress=True arg, or similar. I don't claim to know the usecases that might commonly exist. However, to do that, it sounds like there isn't an elegant solution to how the docstring beyond putting it in the class's docstring instead of__init__'s as@anntzer mentioned.

RegardingOptimizePlus, I'll play with that and add that in if that seems to generally improve things. The linked documentation sounds like the various optimize options all have their good/bad, so that's another point in favor of allowing ano_compress=True +extra_args for those who really want to tweak output with more control of ImageMagick.

Btw, still curious if there's a faster method of iterating on checking the generated docstings.

Basically, committing to one's memory that the compress kwarg to ImageMagickWriter improves the size of the movie is a totally non-generalizable knowledge. It doesn't help you if you want to use imagemagick directly (and the imagemagick docs will obviously not point to that kwarg either), and it doesn't help you either if you switch to another animation writer class. Also, if imagemagick decides later to introduce a better optimization flag (OptimizePlusPlus), do we need to keep "compress=True" mapped to Optimize for backcompat?

Re: docs build: yeah, it's a bit of a pain. Builds after the first should be less awfully slow, though.
There are a few places where we use string interpolation to reuse parts of docstrings (see e.g. the spectral docs in mlab.py) but it's a bit of a mess and I would suggest not doing it unless really needed.

@anntzer That makes sense.

I guess we can't make it the default then though, because there'd be no way to override...

You can put it as default inrcParams["convert.extra_args"]? Then it's overridable by setting the rcparams.

That seems reasonable to me.

I'll check that out and update the PR sometime in the next week or so 👍

Any progress here?

I've gotta dig into the rcparams stuff a bit before I can do the suggested changes. Maybe this weekend.

I don't anticipate digging into this code again, unfortunately. Feel free to close.

Superseded by#23371. Thanks for the suggestion!