error in os.chdir

[eryk sun]

On Sun, Jul 1, 2018 at 2:28 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, Jul 1, 2018 at 12:22 PM, eryk sun <eryksun at gmail.com> wrote:
>>> So what if, internally, that's done by converting them to backslashes?
>>> No Python program needs to care. In fact, there are other conversions,
>>> too - the underlying file system is most likely using UTF-16 paths,
>>> but your Python program needn't use UTF-16. No, it simply uses a plain
>>> old string literal - a Unicode string. The OP need not be concerned
>>> about any of these fiddlinesses, unless in some way they actually
>>> affect Python.
>>
>> A few minor changes in in wording are both technically correct and
>> don't make the text any more difficult to understand. You're the one
>> blowing this up beyond proportion and making a mountain out of a small
>> technical-correction mole hill. Please just let it pass.
>
> If you can show me a way in which a Python program actually needs to
> care about any of these distinctions when dealing with files on
> Windows, then I'll admit that the technical correction was needed. You
> won't be shelling out to the "dir" command, for instance.

Python has no built-in support for Windows file security, so a Python
program may decided to use icacls.exe, takeown.exe, or xcopy.exe (copy
owner/ACL). It's best in general to normalize paths when integrating
an external program -- unless you've already checked that the
program(s) you're running support forward slash without a problem.
Checking this in each case isn't worth the trouble when it's so simple
to call normpath(). Doing a quick test isn't sufficient. Programs that
fail in this case do so in different ways and not always consistently.
Using forward slash may work in some cases (e.g. passing a explicit
file vs passing a wildcard pattern), which may give someone a false
perception that the program intentionally supports forward slash as a
path separator, when it's only working by accident of implementation.