-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide expanduser() on Path objects #63975
Comments
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 |
Documentation, please (Doc/library/pathlib.rst)! This is the docstring of Path.cwd. """Return a new path pointing to the current working directory This is the docstring of Path.expanduser. 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 |
I think it shouldn't. (Or shouldn't be set to True by default anyway). . 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.) |
Let's see what POSIX says: """ 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:
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': |
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 ====================================================================== 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 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:
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': |
Ok, test_pathlib now pass on the buildbot "PPC64 AIX 3.x". I close the issue. Nice enhancement of the Path object. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: