> Ah, I think I follow now. But I'm not sure what you mean by wanting it to "retain an initial '.' component" - how would you expect that to work in practice? p1.parts == ('.', 'c:a')? I suspect that could break existing code.

I've dealt with that in my PR by checking in the __str__ method if the path could be misinterpreted, and if so prepending a './'.


> > The CreateProcessW case is a generalization of the case that we're used to across various platforms, in which, for the sake of security, the "." entry is excluded from PATH. In this case, the only way to run an executable in the working directory is to reference it explicitly. For example (in Linux):
[...]
> > This would work if pathlib kept the initial "." component.

> Thanks, this is a really useful example, as it makes it clear that this is a general issue, not a platform-specific quirk.

In my opinion, this is a different problem, that its solution doesn't necessarily belong in pathlib. Pathlib is responsible to parse, manipulate and display paths correctly (which it fails to do with the case of Path('./a:b') -> Path('a:b')). In contrast, in the case of CreateProcessW, both Path('./exec') and Path('exec') are the *correct* paths to the executable. The ./ is not necessary in that case to display the path correctly, but just to interact correctly with CreateProcessW's interface.

> Having said all of this, I'm not at all sure how much it relates to the original description of this issue, which didn't mention initial './' components at all. Is the originally reported behaviour a *consequence* of not retaining './', or is it a separate problem? If the latter, then maybe "Pathlib should retain an initial './'" would be better raised as a separate bpo item (and PR)?

I completely agree that any change made to support retaining the initial './' for process invocation should be made in a different bpo item and PR. I do disagree though, that such change should be made, as like I wrote above, this is only needed for CreateProcessW's interface, and isn't related to pathlib's logic itself.
Maybe, a nice idea would be to open a separate PR that would add a utility for dealing with executing paths. Something like Path.popen(cmd_args, **kwargs), that will call Popen with a path prepended with a './' if needed.