Added pathlib support for several functions - #6660

See also #6655, which does much the same.

See also #6655, which does much the same.

Yes, #6655 adds pathlib.Path support to one function; this adds it to about 7. I could rebase this onto #6655, though, if you'd like... I was waiting to see if #6655 would be merged first, though.

The PR list tends to act like a lifo :) I just saw #6655 as I was going down the list.

I think we are almost there. Could you squash the commits and take a look at the commit message guidelines in doc/source/dev/gitwash/development_workflow.rst. Not sure what to do about the context manager for temporary files, as mentioned there is another PR with one. I'd like to have one available somewhere global, maybe in numpy/testing/utils.py

I think we are almost there. Could you squash the commits and take a look at the commit message guidelines

Thanks! Once we figure out the context manager thing, I'll squash / rebase / fix the commit messages.

+++ to @charris we definitively need context managers for temp dirs and temp files that can be closed without removed in a larger context that tests.

Moreover having functions accepting file descriptor and not only string or file path is a good move in the fact that they will be able to transparently accept in mem (temporary) files.

I've committed a temppath context manager in #6866. If you look there, I also refactor a test to use it. You can get at it (and tempdir) by rebasing on master and importing from numpy.testing.

Great! I'll look into that.

@wackywendell Could you finish this up and squash the commits into one with a rewritten commit message ala doc/source/dev/gitwash/development_workflow.rst?

Hi, sorry - I've been a bit side-tracked in the past month or two; I have a PhD defense in a month, and I'm going through interview stuff now, so this is taking me longer than I planned. I'll try and get it done as soon as I can, though.

Only concern is that it sounds like python-dev is converging on a nicer way to do this that will probably be released in the next 3.4, 3.5 point releases. Maybe we don't care and can always clean this up later once that happens -- I don't have a strong opinion either way.

Probably we should just go for it given that the PR exists :-). I won't merge myself though b/c I'm just thinking about the high-level issue, I haven't actually read the code.

I think we are getting close. @njsmith Should be easy to search and fixup. What changes are being proposed?

EDIT: Is pathlib going away?

@charris: it looks like the current trend is towards adding a standard convert-to-filesystem-path protocol sorta along the lines of __index__, so APIs that take paths and want strings would do from operators import fspath and then

def some_file_function(path, ...):
    # force path to be a str
    path = fspath(path)
    ...

Or something like that.

Also probably pathlib support will get added to a bunch of builtins like open, so that for most code no special handling will be needed at all -- you just write

def some_file_function(path, ...):
    with open(path) as f:
        ...

and it just magically works for both str and Path arguments.

But, it's a mailing list discussion, so -- that's where things seem to be going right now, but, check back next week for our thrilling conclusion :-).

Looks good modulo two style nits.

Thanks @wackywendell .

Sorry to not look at the code -- but is this going to work in py2 with the pypi pathlib2 object? If so -- great!

No, it won't work with pathlib2 because the module name differs. @wackywendell That could probably be fixed.

well, there is a new protocol being proposed -- something like a fspath dunder method. So maybe just wait 'till that gets finalized.

@ChrisBarker-NOAA Probably a good idea. There is also tofile and fromfile to worry about, but they are at the C level and so it will be worth waiting to see what the final interface is.

That protocol has been finalized in PEP 519, and is live in python 3.6