bpo-44316: add keep_curdir and keep_pardir arguments to os.path.normpath()

[barneygale]

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

[github-actions]

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

[asarfraaz]

Hello Barney,

Would the fix in this commit help solve the question mentioned here : https://stackoverflow.com/questions/62687193/how-to-create-a-pathlib-relative-path-with-a-dot-starting-point ?

Was curious to know if the code changes for this Pull Request were ever added to the main code ?

[barneygale]

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.

[asarfraaz]

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.

[barneygale]

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.

[asarfraaz]

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.