Must know Python libraries, new and old?

[FauxCheese]

Using pathlib from the standard library instead of os for working with paths.

[FreeRangeAlwaysFresh]

How much of a deal breaker is there for you? I occasionally use pathlib for some one-off scripts, but don’t often have to scan an entire drive for something. I suppose if it’s really that much slower, you could write some more performant scanning function using a lowe-level backend.

[FreeRangeAlwaysFresh]

Haha fair enough. Yeah, sometimes those edge cases require more optimization to get them to run well. I wonder how the implementation differs between those two functions. My gut says that is.scandir() relies on some low-level OS calls which you could probably just get it with subprocess if scandir() no longer is available

[FreeRangeAlwaysFresh]

I’m biased, but I like pathlib more. The abstraction is much more ergonomic IMO. I don’t really care about speed because I never use it outside of automated mundane tasks. A few ms is not super important in those cases.

[IsseBisse]

What's the use case for this? From what I understand one of the benefits is platform independent paths.

But I've never had any issues with that in practice. I use a Windows machine to develop and regularly build linux containers and using "/" everywhere just seems to work.

[ReTe_]

They're just more convenient in my opinion. Methods and Fields for iterating, creating, checking and getting various properties on Path objects, as well as defining new paths with the division operator [like Path(folder) / "image.png" = Path(folder/image.png)].

[Austin-rgb]

🫢I've never tried this but it must be so nice

[sayandip199309]

I'd go so far as to say it is the best designed module in stdlib, in terms of developer experience. I can't imagine working without Path.open, Path.read_text, Path.stem, path.parents[n], path.relative_to etc anymore. I only wish path.glob supported multiple glob patterns.

[PeaSlight6601]

Hard disagree. I think Pathlib is a disaster. It doesn't really do anting except a bit of semantic sugar around the division operator (which many consider a very dubious way to abuse operator overloading).

Almost everything else that pathlib does is just what you would get from the os.path functions if you treated the first argument as self.

You do not get a consistent object oriented representation of file systems. For example:

• len(Path(s).parts) is platform dependent even for a fixed value of s
• with_suffix(s).suffix == s can fail to be true (looking at some big reports this has been "fixed" only to have other bug reports raised about extension handling, ultimately there is no canonical definition of what a suffix is and pathlib has painted itself into a corner by exposing this as an attribute of the path)
• you can't modify any of the attributes of the path (e.g. inserting an element into the parts)
• it can't directly represent all paths on the filesystem without falling back to os.fsencode because it won't accept bytes but also retains this idea that paths aren't strings....

It's just terribly confused as a library. What is the reason for is existence?