Python 3 (-), Old Man Yells At Cloud 

I was appreciating the fact that with Python 3, we finally get a Path type in the standard library.

Until I discovered that `Path('/var/www').joinpath('/etc/passwd')` doesn't throw `InsecurePath`.

Okay, I can imagine there are some use cases where you want to be able to represent `foo/../../assets` or something, but usually not, and resetting the root to `/` never.

which is why t.p.filepath has guarded against that sort of thing since its inception in 2003.

Come on, stdlib, where are my Batteries Included? PEP 428 even cites t.p.filepath as prior art, along with Unipath, which offers a method with similar protections.

I'm checking PEP 428's mailing list discussion, but I don't know how to find this amongst the fucktillion messages debating operator overloading. Maybe that's the answer: everyone who was tired of reading about operator overloading stopped thinking about this PEP.


re: Python 3 (-), Old Man Yells At Cloud 

It was also around the same time as a bunch of the async discussion, so to the extent that anyone who worked with t.p.filepath was paying attention to python-ideas, they were probably trying to keep tabs on that discussion more than pathlib.

extending classes (Kotlin +) 

This also reminds me that Kotlin's ability to extend classes is real nice.

I could define an extension to pathlib.Path that provides a `safejoin` method. Logically, it's the same as providing a function `safejoin(path1, path2)`, but allows the syntax of `path1.safejoin(path2)`. That makes it look consistent with the original methods, and I can use it by importing safejoin without having to make any Path instance I see into an instance of some SafePath proxy or subclass.

Of course, if I pass that Path instance out to any other library, it's likely to still do the unsafe operation, but can't do anything about that without breaking contracts.

Show thread

Kotlin, path manipulation 

Speaking of Kotlin, how does Kotlin standard library deal with paths?

`File("/var/www").resolve(File("/etc/passwd"))` ends up with /etc/passwd, but I am much happier with that named "resolve" than "join".

`File(File("/var/www"), "/etc/passwd"))` doesn't error, but gives /var/www/etc/passwd. You can totally construct /var/www/../../etc/passwd that way, though.

That's `File(File, String)` but there is no `File(File, File)`.

And I don't find any other `File.x(File)` where `x` is anything like `child` or `descendant`.

Show thread

extending classes (Kotlin +) 

@keturn is that by just importing? Like
import safejoin(a,b) from pathlib. ... as a.safejoin(b).

Or do you just mean the ability to extend existing objects?
I liked to do that in js, giving Array or Math some new methodes.

re: extending classes (Kotlin +) 

@Gregor It looks a little like giving Array a new method, but the method only shows up to the places that have asked for it.

Which saves you from any potential headache of you adding a new method to Array and some other lib three levels down the dependency tree *also* adding to Array, but differently 😅

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!