I hit on this because I tested on whether a given filename contains // and if so, I treat it as a URL. But one of my users used the above C://test//abc and so I assumed incorrectly that it was a URL.
My question: any idea why Python accepts superfluous / characters in a file name?
The path gets passed directly to C _wopen(), which calls WinAPI CreateFileW(), which calls NTAPI NtCreateFile(). In CreateFileW(), the system normalizes the path as an NT object path. Among other things, this involves replacing slashes with backslashes and collapsing repeated backslashes. For example:
>>> open('C://test//abc', 'r')
Breakpoint 0 hit
00007ffe`c1454320 488bc4 mov rax,rsp
0:000> du @rcx
Breakpoint 1 hit
00007ffe`c1604f80 488bc4 mov rax,rsp
0:000> du @rcx
Breakpoint 2 hit
00007ffe`c3fef6e0 4c8bd1 mov r10,rcx
0:000> !obja @r8
Obja +0000000000000000 at 0000005cb2deea80:
Name is \??\C:\test\abc
Please do not assume that this means that the Windows API in general “perfectly” supports forward slash as a path separator in file paths. Many file and path functions in the Windows API do not support forward slash as a path separator; “\\?\” extended paths do not support forward slash as a path separator; and file paths passed on the command line often do not support forward slash as a path separator. When in doubt, use the native backslash path separator, unless you’re normalizing the path explicitly via pathlib.Path, os.path.normpath(), or os.path.abspath(). ↩︎