On Sun, Jul 1, 2018 at 2:28 AM, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Jul 1, 2018 at 12:22 PM, eryk sun <eryk...@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. -- https://mail.python.org/mailman/listinfo/python-list