Something like expanduser() may be useful on Path objects.

I wanted to suggest to modify the resolve() method, but '~' is a valid filename... (I tested, and it's annoying because depending on command, sometimes ~ is expanded to /home/haypo sometimes not...)

Hello. Here's a patch for `expanduser()`.

Documentation, please (Doc/library/pathlib.rst)!

This is the docstring of Path.cwd.

"""Return a new path pointing to the current working directory
(as returned by os.getcwd()).
"""

This is the docstring of Path.expanduser.
""" Return a new path with expanded ~ and ~user constructs.
"""

Perhaps we need to add "(as returned by os.path.expanduser)"?

Thanks, Vajrasky! Here's the new version of the patch.

Antoine, is this feature still wanted?

+1

It's very annoying to have to import expand user from os.path, when pathlib should be a full replacement for that module. Thanks to those working on this!

I think that `absolute` method should call `expanduser` and `expandvars` (do you plan to include it?) automatically. This should be optional (via default arguments: `expanduser=True, expandvars=True`.

> I think that `absolute` method should call `expanduser` and `expandvars` (do you plan to include it?) automatically. This should be optional (via default arguments: `expanduser=True, expandvars=True`.

I think it shouldn't. (Or shouldn't be set to True by default anyway).
absolute() method resolves symlinks, and it would make no sense to expand tildes and vars, which are purely a "shell syntax".

. and .. are real things in the filesystem, ~ is just a notation commonly used (since it's in the SCL spec), but it's not *part* of the path, that's why you can totally have a valid ~ file.

Making absolute() expand tildes would be illogic, unintuitive and unpythonic.

(+1 for the .expanduser() patch though, I went here after searching for this feature in the docs).

Added a new version of the patch with improvements suggested by Berker Peksag. Thanks for the review!

Antoine, how does my latest patch look?

Claudiu, sorry for the delay. I'm going to take a look soon!

Attached the new version of the patch with fixes according to Antoine's review.

Since all the comments have been addressed, it would be nice if this gets committed.

This new patch fixes some comments from Serhiy. Thanks for the review!

Doc example is still looks confusing. Is your home directory /home?

There is a question. What should pathlib's expanduser() do in case when user directory can't be determined (or user does not exist)? Perhaps unlike to os.path.expanduser() it should raise an exception (as in many other pathlib's methods).

No, my home directory is actually /root. The attached patch should be clearer now (I hope). Regarding your question, wouldn't checking for this duplicate what os.path.expanduser already does? (Unless checking for the exact same string before returning it.)

> There is a question. What should pathlib's expanduser() do in case
> when user directory can't be determined (or user does not exist)?
> Perhaps unlike to os.path.expanduser() it should raise an exception
> (as in many other pathlib's methods).

Let's see what POSIX says:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01

"""
If the system does not recognize the login name, the results are undefined.
"""

Helpful, isn't it ;-)

Behaving like os.path.expanduser() would have the advantage of consistency (which is in turn consistent with Unix shells), OTOH, it seems wrong to just return the unexpanded form: for example, if someone calls expanduser('~apache') and there's apache user, returning '~apache' could be dangerous if there was an '~apache' folder in the CWD.

So I think it would be better to raise an exception.

Here's a version of the patch which raises ValueError when the path can't be expanded. Hopefully, the used approach is good enough.

Here is alternative patch which doesn't use os.path.expanduser() and reimplement it's logic. Differences:

* expanduser() is part of concrete path API. This method access environment.
* RuntimeError is raised when user home can't be determined.
* Currently ntpath.expanduser() uses heuristic to expand path with specified username. This works with default homedirs but can return wrong result when homedirs was moved to different locations. WindowsPath.expanduser() also uses heuristic, but more robust. Of course it would be better to get other users homedirs from Windows API, and perhaps we should defer this issue until implementing pwd or like on Windows.
* Expanded tests.

Interesting, common idiom to escape tilda in relative path (adding "./" prefix) doesn't work with pathlib, because "." components are ignored.

Looks good.

Serhiy, would you like to update your patch?

Sorry. Here is updated patch.

Steve, would you like to give an opinion on the Windows aspects of this patch? Otherwise I will simply commit it soon.

I thought that USERPROFILE was the preferred environment variable and should be checked before HOME, but I could be wrong. Consistency with the existing expanduser function is more important probably.

There's almost certainly an API to find an arbitrary user directory, but it may only be available to administrators, so the guess is probably necessary anyway. The directory name doesn't necessarily match the user name either, especially since a lot of Windows users these days authenticate with their email address.

New changeset bee697b0fd18 by Antoine Pitrou in branch 'default':
Issue #19776: Add a expanduser() method on Path objects.
https://hg.python.org/cpython/rev/bee697b0fd18

The test fails on the buildbot "PPC64 AIX 3.x". It looks like the home directory of the buildbot slave user is /home/shager/.

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/2994/steps/test/logs/stdio

======================================================================
FAIL: test_expanduser (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_pathlib.py", line 2002, in test_expanduser
    self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')

I don't really know how to investigate that failure. Perhaps David wants to look into it?

> I don't really know how to investigate that failure.

I don't think that it's specific to AIX, it just depends on the list of users on your system. On my Fedora 21, I have many users which have an empty home directory:

- nobody
- dbus
- polkitd
- usbmuxd
- nm-openconnect
- tcpdump
- qemu
- radvd
- systemd-journal-gateway
- systemd-timesync
- systemd-network
- systemd-resolve
- systemd-bus-proxy

If the test pick one of this user instead of a user with a non-empty home directory, the test fails with the same error. I propose a simple patch: test_pathlib_empty_homedir.patch

Victor, your patch sounds ok to me.

New changeset 63dac5212552 by Victor Stinner in branch 'default':
Issue #19776: Fix test_pathlib.test_expanduser()
https://hg.python.org/cpython/rev/63dac5212552

Ok, test_pathlib now pass on the buildbot "PPC64 AIX 3.x". I close the issue. Nice enhancement of the Path object.