error in os.chdir

[Steven D'Aprano]

On Sun, 01 Jul 2018 03:18:23 +0000, eryk sun wrote:

> On Sun, Jul 1, 2018 at 1:44 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> On Sat, 30 Jun 2018 23:36:40 +0000, eryk sun wrote:
>>
>>> Only use forward slashes for legacy DOS paths passed to Windows API
>>> functions. Do not use forward slashes for paths in command line
>>> arguments, \\?\ prefixed paths, or registry paths.
>>
>> I don't see why this is relevant, or at least not the "command line
>> arguments" and "registry paths" parts.
> 
> Command-line arguments are relevant to executing a child process, e.g.
> via subprocess.Popen.

Ah, yes they are. But using subprocess is a little more of an advanced 
use than regular file handling. But your point is taken.


>> I guess that if the user is using a path beginning with \\?\ they may
>> or may not need to use backslashes, but I have no way of testing it,
>> and I would expect that Python will correctly replace //?/ with
>> backslashes the same as it does for any other file system path.
> 
> The Windows API handles this, but not for a path that begins with \\?\.

But what about the *Python* API? The Python open() function, and all the 
high-level os.* and os.path.* functions which take paths as strings are 
supposed to automatically convert forward slashes to backslashes. Aren't 
they?


> The intent of this prefix is to bypass DOS-path normalization --
> allowing paths with length up to 32K characters that can use otherwise
> reserved DOS-device names or names ending in spaces or dots.
> 
>> (Besides, Python doesn't have an API for interacting directly with the
>> registry.)
> 
> The standard library has winreg -- or _winreg in 2.x.

Oh, I live and learn.


> Bear in mind that forward slash is just a  name character in NT.

Interesting... 

That's rather like on HFS Plus, where / is an ordinary character allowed 
in file names (although Mac OS goes to extraordinary effort to ensure 
that tools that expect / as a path separator see it, and those which 
expect : as the path separator see it instead).


> We only need to clearly state that the
> Windows API allows using forward slash as the path separator in file
> paths that do not begin with the \\?\ prefix. I prefer to also add a
> warning about command-line arguments, since it isn't an improbable or
> inconsequential problem

Fair enough.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson