astropy
Determine if the `EPSFFitter` can be a regular astropy fitter
Right now the EPSFFitter is not a sub-class of astropy.modeling.fitting.Fitter. It would be better if it were, as it could then simply be treated as sort of a "drop-in replacement" for other fitters (or vice versa).
It seems like this should be straightforward - just change the subclass and make sure any missing abstractmethods are implemented. But that's famous last words there...
cc @larrybradley
I don't quite see what this would achieve from a cursory glance. EPSFFitter is passed an astropy.modeling.fitting.Fitter which does the actual heavy lifting of the determination of coordinates and flux scaling for each source, all of which is wrapped (i.e., about N-7 lines of the code in EPSFFitter) in code that handles the EPSFStar functionality. The subarray source extraction, fit box size checks, joining together of linked sources across images, updating of EPSFStar object values, and definitions of ePSF oversampling (although see #725 for changes to this) are all "outside" of any remit of an astropy.modeling.fitting.Fitter. The "drop-in replacement" is the option to pass a non-astropy.modeling.fitting.LevMarLSQFitter as far as I can tell.
Perhaps the name is misleading? It does make it sound like it itself is the fitter to an ePSF, but it is almost entirely paper shuffling to maintain EPSFStar objects and handle various edge cases, with a very brief moment of actual model fitting once all of the players are in place. I suspect documentation and simple user cases might help clear up this confusion as well...
