python pathllib joinpath() drops part of main path if other path starts with slash

pathlib Path joinpath() seems to drop subfolder of main path if joining with other path starting with forward slash

from pathlib import Path
a = Path(r'c:\main_folder')
a.joinpath(element_a)
element_a = r'subfolderX/subfolderXY/file.txt'
Out[]: WindowsPath('c:/main_folder/subfolderX/subfolderXY/file.txt') # expected
element_b = r'/subfolderX/subfolderXY/file.txt'
a.joinpath(element_b)
Out[]: WindowsPath('c:/subfolderX/subfolderXY/file.txt')  # ?! missing 'main_folder'

joining path with element_b the result is missing 'main_folder' (!)

I must be missing something (fundamental) , since I find this very much confusing and leading to hard to find bugs

Firstly I would expect pathlib and its methods purpose is to gracefully handle filepaths intricacies to shield developers of dealing with this ugliness. Save for ambiguous cases, but then ->

Secondly, if ambiguous situation (windows vs posix differences or whatnot) I'd expect the library or method crash \ won't allow to use it, rather than silently give me unexpected result

and thirdly, mainly, I'd expect joinpath() method to join the two paths above anything else

I see in joinpath() docs it returns a
new path representing either a subpath (if all arguments are relative
paths) or a totally different path (if one of the arguments is
anchored)

What is 'anchored' and how to work around it, if I am constructing a path out of various elements, some configured, some provided by users, some stripped of other paths am I back to awkwardly manually testing for the slashes and constructing various string concatenations based on that?

The leading \ functions as an anchor to the drive. An unanchored path can be added to other paths, but an anchored path has some reference to where it points to, relative to some other path. So the leading \ binds it to the root of the current directory tree, in your case C:\.

Your command is interpreted like so:

• Go to C:\main_folder
• Follow \, which brings you back to C:\
• Go to subfolderX\subfolderXY\file.txt from there.

Effectively, you are telling python to join C:\main_folder and C:\subfolderX\subfolderXY\file.txt together.

If an anchored path is given to joinpath, then the first path segments will be ignored as described in the Doc.

The most simple way to discard leading slashes would be to do "\\abc\\".lstrip("/\\") This will remove zero or more leading leading / or \ characters.

> Firstly I would expect pathlib and its methods purpose is to gracefully handle filepaths intricacies to shield developers of dealing with this ugliness. Save for ambiguous cases

Which it does, joinpath handles upwards and root (anchored) traversals for you.

> Secondly, if ambiguous situation (windows vs posix differences or whatnot) I'd expect the library or method crash \ won't allow to use it, rather than silently give me unexpected result

That doesn't make any sense, the goal of pathlib is not to provide a half-assed common subset of all possible filesystems (that would be completely incapable since some filesystems / APIs don't even have directories). \ is a path separator on windows, and it's a regular character on unices, that's just a thing.

The module documentation literally tells you:

> This module offers classes representing filesystem paths with semantics appropriate for different operating systems.

So it follows the semantics of the current system, if you want the semantics of one system over an other, use the Pure*Path objects as it also tells you:

> If you want to manipulate Windows paths on a Unix machine (or vice versa). You cannot instantiate a WindowsPath when running on Unix, but you can instantiate PureWindowsPath.

> and thirdly, mainly, I'd expect joinpath() method to join the two paths above anything else

Which it does. It essentially acts as a bunch of directory traversals (cd).

If you just want straight up string manipulations, you already have string manipulations, there's no need for a dedicated module.

> What is 'anchored' and how to work around it, if I am constructing a path out of various elements, some configured, some provided by users, some stripped of other paths am I back to awkwardly manually testing for the slashes and constructing various string concatenations based on that?

If you consider thing.strip('/') to be "awkwardly manually testing for the slashes" then yes. You'll face the same issue in more or less every language, they don't provide filesystem path manipulation for trivial string concatenations, that'd be dumb.