I can't figure out this warning:

None:None: WARNING: toctree contains reference to nonexisting document '_generated/xml.dom.minidom.parseString'
<autosummary>:None: WARNING: toctree contains reference to nonexisting document '_generated/xml.dom.minidom.parseString'
None:None: WARNING: toctree contains reference to nonexisting document '_generated/xml.dom.minidom.parseString'
writing additional files... (13 module code pages) _modules/index
 genindex py-modindex np-modindex search
copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 24 warnings.

the object xml.ParseString is imported in nedpy, but never mentioned in the docs or really anywhere. Working on the others...

There are major problems with nedpy that I can't fix. Each nedpy function includes a table, and I think numpydoc chokes on that table, especially since it is surrounded with ---------. Any ideas?

I really like having the tables there, but if we have to, we can just strip the docs to get builds to pass.

I'm taking a look at some of the failures

@keflavich - see keflavich#1 for some Python 3 fixes.

How about using python-requests everywhere in astroquery?

From it's website:

Python’s standard urllib2 module provides most of the HTTP capabilities you need, but the API is thoroughly
broken. It was built for a different time — and a different web. It requires an enormous amount of work (even
method overrides) to perform the simplest of tasks.

It's a small pure-python dependency, well-done and -maintained and will make the astroquery code simpler (e.g. none of these Python 2 / 3 changes). It seems to me that would significantly lower the barrier for astronomers like me that know very little about the Python stdlib HTTP packages to be able to contribute.

@keflavich @astrofrog What do you think?

@cdeil - I was thinking along the same lines. I think that wherever possible, get_readable_fileobj should be used, but otherwise requests could be used for actual queries.

+1 to using requests - it is a pretty easy interface. I'm going to make that into its own issue.

@keflavich Can you go through the issues and add labels, assignees and maybe a milestone (or add a "later" label). I'm having a hard time figuring out what I should / can be working on. Feel free to assign a few things to me ... I will ask for help if I can't figure it out.

On this issue, anyone can help - the python3 failures are probably mostly a refactor need; every urllib request errors saying E TypeError: POST data should be bytes or an iterable of bytes. It cannot be str.

@cdeil - I did add milestones and labels, but honestly haven't put a ton of thought into them. I think the most interesting thing to do right now would be to work on developing the FermiLAT tool into a working example of the proposed API to make sure it really makes sense.

If either of you can help with the sphinx build errors in nedpy, though, it would be greatly appreciated. The python3 errors are somewhat overwhelming - they pervade the entire code base - but the nedpy docs are at least reasonably isolated.

New PRs will be needed for

1. nedpy docstring fixes
2. python3 compatibility fixes