Various modifications for ProPlot

[lukelbd]

Not sure if you guys will necessarily want to merge this as it changes some core behavior, but I forked this for use with my proplot project and added the following features:

• Skip over class methods that are public, but do not have their own __doc__ attributes. This prevents inheriting and displaying documentation from external projects, namely matplotlib.
• Include __getitem__, __getattr__, __setitem__, and __setattr__ in the list of builtin methods that are not ignored by the documentation generator. I use these to document some dictionary/list subclasses.
• Give class methods and attributes their own stub pages, instead of putting all class methods and attributes on a single page. This also required adding the new files to env.found_docs and reordering the event hooks in automodsumm.py so that sphinx_automodapi is called before autosummary. This way autosummary sees the new class pages and builds the appropriate stubs.

Related:

• 102

• 103

• 104

[lukelbd]

Let me know if you guys have any interest in merging this (I can squash and force-push the messy history).

If so I could implement these features as configurable options so the changes are backwards compatible, e.g. an automodsumm_ignore_nodoc = True to skip methods with __doc__ == None, automodsumm_include_methods = ['__init__', '__call__', '__getitem__', ...] to explicitly include certain private and hidden methods (the default would just be __init__ and __call__), and automodsumm_method_stubs = True to enable individual pages for method stubs. Would be relatively simple.

[astrofrog]

@lukelbd - thanks for the PR and sorry for not responding sooner! I think some of these options sound like they would be useful to some users although for example for astropy we wouldn't want one page per method/attribute since we we would end up with waaaay too many pages. This PR as-is also includes a lot of changes that are specific to the proplot fork, e.g. the changes to the readme and so on. So I was wondering if you could open a separate PR for each conceptually different addition, and indeed avoid changing the default behavior, but make these things configurable as mentioned in your latest comment? I think all three features could be merged in if they were configurable and defaulted to the current behavior.

[lukelbd]

@astrofrog Sounds good! I'll do that when I get the chance, maybe some weekend later this month. Will close this PR since it will be replaced by 3 others