Replace `os.path` with `pathlib.Path`
See original GitHub issue🚀 Feature Request
Motivation
os.path
gives cross-platform filesystem operations, but it’s a cumbersome API because the primitive is a string. Since Python 3.4 pathlib
has been available in the Python standard library, which makes some common filesystem operations available with better ergonomics.
Pitch
Replace use of str
paths with pathlib.Path
and migrate away from os.path
APIs to pathlib
APIs. This can make the code much clearer in some cases.
Alternatives
Leave the code as is.
Additional context
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Migrating from OS.PATH to PATHLIB Module in Python
Learn how to use the modern pathlib module to perform tasks you have been using os.path for.
Read more >pathlib — Object-oriented filesystem paths
Source code: Lib/pathlib.py This module offers classes representing filesystem paths with semantics appropriate for different operating systems.
Read more >Is there a Pathlib alternate for os.path.join? - python
Yes there is: env_path = Path(__file__).parent / ".env". / is all you need. This will work in different OSs.
Read more >Is pathlib a viable replacement for os.path?
So far I have used only os.path, and as I have stumbled over that topic in a guide I am reading, it got...
Read more >Why You Should Start Using Pathlib as an Alternative ...
To do this, I typically use the os.path Python module to perform operations such as joining paths, checking the content of a directory, ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
As an aside: this might also be a good opportunity to gradually add type hints to the code in hopes of catching more bugs with a linter and to generate better API docs.
One example is this. When I first read this when trying to debug #2847, I realized the semantics are ambiguous: this could refer to hidden files (i.e.,
".model/"
) or relative paths specified a certain way (i.e,"./model/"
). There are other fairly common ops like “path.suffix” which are logically used extensively to filter out certain extensions throughout the codebase. By adding a path object, we have a lot of flexibility by way of expressive semantics.I’m happy to spin off a draft PR to see what the benefits actually look like. 😄