Looks fine. I might have misguided you a bit on the mailing list by suggesting that you looked at my branch (#1420). As @WeatherGod pointed out it is not a good idea to have a mutable type (in this case an empty dict) as the call signature default.
See commit for an 63733aa for an alternative solution and http://www.siafoo.net/article/52#id41 for an explanation why. Otherwise this look very good.

Thanks very much for this review, @jenshnielsen . I wasn't aware of the danger that mutable types present when used as default arguments, and just pushed a fix for this (see 5f42166). Regarding commit 63733aa which you referenced, perhaps I'm missing something but I don't see how this issue is fixed there since the dict() that it uses as the default value is still mutable. Anyway, many thanks for pointing this out!

Sorry wrong comit it should have been 6d585f3 which is identical to what you just did. IMHO this looks good now and should be ready to merge

Ah, that makes more sense. :) Thanks again for your quick and helpful responses!

P.S.: I just discovered a small bug which is introduced/exposed by this change in the Animation class. I'll ask about this on the mailing list, but perhaps it's best to wait for comments there before merging (or perhaps it can even be fixed easily).

Fixing the bbox_inches issue is going to be tricky. bbox_inches is probably one of the most commonly used kwargs in savefig, and most people are going to expect it to work. The problem is that it if bbox_inches='tight' (the most common usage, IMO), then bbox_inches='tight' is applied to each and every frame of the animation, which may or may not change. We could easily define that the tight bounding box would be derived from the first frame, and that may be sufficient.

The other difficulty that may arise here is the order of operations. We would have to know the figure size prior to initializing the mencoder or ffmpeg stream, but a tight bbox can't be known until the first frame is drawn. This may require a little bit of tweaking in the animation saving code.

Because bbox_inches is such an important kwarg for savefig, I would suggest either holding off on merging for a bit, or to include a warning in the save() docstring that the bbox_inches='tight' option is currently ignored (and to pop it out if it exists in savefig_kwargs).

Thanks for the suggestions, @WeatherGod . I have now added a check to drop the 'bbox_inches' argument if a writer is being used that doesn't support it (and issue a warning in this case). I hope this resolves the issue sufficiently to make the branch merge-able (because 'bbox_inches' is useable with some writers, so no functionality is too severely limited).

I like the warning. I'm not sure if we should be whitelisting only mencoder_file and ffmpeg_file, or if we should just blacklist their pipe-based counterparts. It's relevant because we also have the (newly added) ImageMagick writers. I don't have an animation with a changing bounding box, so I can't really test if either (or both) ImageMagick writers will work--I suspect they both will. Can someone test?

I tested the 'imagemagick_file' writer yesterday before uploading the new commit, but it didn't work (I even got an error message), so I didn't whitelist it. I have now also tried the 'imagemagick' writer. I don't get an error, but the animation file it creates has size zero. I tried to take a look into why this happens but don't really have the time to debug at the moment. It seems to me that it's safer to whitelist writers that are kown to work instead of accidentally forgetting to blacklist a broken writer. We could merge the change as it is (if there are no other objections) and also whitelist the imagemagick writers once they work. Any other opinions?

So, there haven't been any comments on this for a while. It seems to me that this is theoretically ready to merge, unless I missed any fundamental objections. The only open question was whether we should whitelist or blacklist writers for use with the bbox_inches argument. At the moment I have whitelisted the writers ffmpeg_file and mencoder_file only because AFAICS these are the only ones that work. I tested with both imagemagick and imagemagick_file, too, but neither of these works at the moment (see my previous comment). So it see seems to me that whitelisting is currently the better option. We can always change it down the line if we get other writers to work. Any objections against a merge at this point?

I kept meaning to test imagemagick, but haven't found the time. I'll just merge.

Thanks! Yes, it's strange that the imagemagick writer gives me zero file size. Unfortunately, I won't have the time to debug this anytime soon, but I'll keep it in mind in case I find a few spare hours.