bpo-44316: add keep_curdir and keep_pardir arguments to os.path.normpath() by barneygale · Pull Request #26694 · python/cpython (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation6 Commits2 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

Retaining '..' entries ensures the path's meaning is preserved in the presence of symlinks. This functionality was previously available only in pathlib.

Retaining '.' entries helps ensure shells don't interpret paths differently (compare ./python and python). Thanks to @eryksun for the suggestion.

https://bugs.python.org/issue44316

When set to True, .. entries are retained, which ensures the path's meaning is preserved in the presence of symlinks.

This functionality was previously available only in pathlib.

barneygale changed the titlebpo-44316: add strict argument to os.path.normpath bpo-44316: add strict argument to os.path.normpath()

Jun 12, 2021

barneygale changed the titlebpo-44316: add strict argument to os.path.normpath() bpo-44316: add keep_curdir and keep_pardir arguments to os.path.normpath()

Jun 13, 2021

This PR is stale because it has been open for 30 days with no activity.

By design, pathlib normalizes . tokens out of paths, as it considers them spurious. From the docs:

Spurious slashes and single dots are collapsed [...]:

>>> PurePath('foo//bar')
PurePosixPath('foo/bar')
>>> PurePath('foo/./bar')
PurePosixPath('foo/bar')

I'd like to make this customizable in a future edition of pathlib, but it's a ways off yet. The code in this PR hasn't landed anywhere, and probably won't given there's now a C version of the same function.

Thanks Barney.

I was finding it hard to understand why a leading dot like ./script.sh would be considered as spurious.

I hope that this gets addressed.

I am assuming that, as of now, pathlib would not be of much help to me for handling the leading dot scenario. And most probably will only have to hope that it will be fixed sometime in the future.

I was finding it hard to understand why a leading dot like ./script.sh would be considered as spurious.

In many cases it is spurious, e.g. cat out.txt and cat ./out.txt are the same thing. It only matters when it's the first argument of a shell command, I think.

And pathlib should support that, eventually, IMO.

For now I recommend you use strings and os.path, or dump a ./ in front within your code.

I agree that pathlib should support a leading dot since it is a valid case for executing a shell command.

I was almost on the verge of implementing os.walk functionality with pathlib, but got stuck up with this case :-) I did not want to use os.path for this, so going to use f-strings instead.

On a side note, may be the reason for pathlib to worry so much about spurious items in a path, is a fall out of the code trying to fix a negative test case and missing out on a valid positive scenario ( of shell scripts ). May be pathlib should have left the decision about spurious dots to the application ( shell globbing in the case of the cat example you mentioned above ). It would probably be a more clean and flexible design. But anyways, may be I am only seeing it from the shell scripting perspective and not sure what other use cases mandated pathlib to worry about spurious items in the path.