Support for Path objects in io packages - #4606

@taldcroft Is this the correct approach? I tried to follow yours as in #4405.

@anchitjain1234 - thanks, this looks promising! If you do a census throughout the project of places that use get_readable_fileobj, I would be nice to see demonstration through testing of this fix being more broadly applicable than just io.ascii. I'm not sure off-hand how io.fits and io.votable handle the front-end task of handling the "input" file, which might be one of many different object types.

If you do a census throughout the project of places that use get_readable_fileobj, I would be nice to see demonstration through testing of this fix being more broadly applicable than just io.ascii.

@taldcroft I grepped the whole project to find the usage of get_readable_fileobj. Check results here.
From the above results, I think I have covered through tests io.ascii, io.votable and utils.
But I am not sure if vo also needs to be tested? because it uses get_readable_fileobj to get data from URL only

I'm not sure off-hand how io.fits and io.votable handle the front-end task of handling the "input" file

I handled io.fits directly in _File class and io.votable is automatically accepting pathlib.Path object because it uses utils.xml.iterparser which in turn uses get_readable_fileobj.

I also added a separate test for votable.validate because it uses get_readable_fileobj directly to get content.

@taldcroft Could you please check the changes?

@anchitjain1234 - looks pretty good, thanks!

Also pathlib can be installed on PY2: https://pypi.python.org/pypi/pathlib2/
So it is better to avoid testing for PY3 as @taldcroft said.

@taldcroft Please check the changes.

@anchitjain1234 - looks good! Now you just need to add an entry to CHANGES.rst describing this update. You can put [skip ci] in the commit message to avoid re-running CI testing.

@taldcroft In Python 2 pathlib is pathlib 2 therefore import pathlib would not work. So do I need to add import pathlib2 statements also?

@anchitjain1234 - Even if the package name is pathlib2, it will import as pathlib.

@taldcroft - Maybe the extra dependency should be added to a Python2 build in Travis ?

@taldcroft Changelog entry added.

@saimn - I think that @anchitjain1234 has a point. If pathlib2 is installed the code still needs to explicitly do:

import pathlib2 as pathlib

I was hoping that pip install pathlib2 did a magic rename so that import pathlib would work on Py2, but I just tried and that is not the case. So this leads to the uglyness:

try:
   import pathlib
except ImportError:
    try:
        import pathlib2 as pathlib
.. etc

I think we should just merge this current version, which addresses the stated issue of providing support for bona-fide pathlib.Path objects. Supporting the Python2 backport can be a separate issue, but I think it will need to go along with refactoring the HAS_PATHLIB logic into a separate single entity.

@taldcroft - Ah sorry, I tested this on a virtualenv, that I thought was based on PY2 but it seems not. The backport provides indeed a pathlib2 package, and this is intentional : jazzband/pathlib2#8 (Probably for good reasons even if it is not handy).

Thanks @anchitjain1234 ! And @saimn for useful review and input.