Paths can't be converted tostr as this implies an interpreter defined encoding.

Can you explain what you mean by this or give an example?

Before the change it looked like this:

path = stage_blob[1].path

And after the change it should still be looking like this but possibly with type annotations added to please the type checker. Creating new strings withstr(…) changes the way the program functions, and does so in a breaking way due to encodings being unspecified for paths on linux.

Changed to use paths instead of strs. Still not really sure what you mean by encodings being unspecified for paths on linux.

There has to be a way to do this withoutstr(…), please see above for the reason.

Is this not another way of writingpath1 == path2, since all path components (here.parts) have to be equivalent? The benefit of doing so of course is that it ignores which path separator is used, but I am having trouble to understand how this checks thatblob_path starts with one ofself.paths.

I think this should work becausezip stops when the shortest of the arguments is exhausted. So it is only checking ifall the path components are equivalent in the case that the length of theparts are equal. But, when one path has more parts than the other, then it is checking that the longer path starts with the shorter path.

Example:

defstartswith(a,b):returnall(i==jfori,jinzip(a,b))a= [1,2,3]b= [1,2]assertstartswith(a,b)

Alternatively, the implementation ofPosixPath.is_relative_to looks like this:

defis_relative_to(self,*other):"""Return True if the path is relative to another path or False.        """try:self.relative_to(*other)returnTrueexceptValueError:returnFalse

We could do something similar to this in-place.

Thanks for the explanation, I see how this works now and why this is correct. The alternative has to remain a TODO until it becomes available, and looking at the code I am happy to suggest to not ever go there - the try:except clause seems like a deal-breaker to me. It's entirely up to you though.

Actually, let me undo what I last said. I once again think this implementation is incorrect, as these paths are not equivalent.

base= [1,2,3]added_path= [1,2]

The above would match even thoughadded_path is not contained in base.

Good catch, I pushed a change that addresses this and adds a test too.