On 14/11/2013 00:21, Laurent Birtz wrote:
> Is it reasonable to believe that most Python programs don't care
> about the legacy shell API? 

No more than it is to believe that most Python programs don't care about
MSys or Cygwin ;)

For information, cmd.exe will happily run, eg, "c:/windows/notepad.exe".
The problem is that command-line programs built in to cmd.exe (such as
"type" and "dir") expect the slash to prefix a command-line switch. And
they don't seem to have particularly good escape- or quote-handling.
External command-line tools, like "xcopy", will happily act on
forward-slash pathnames as long as they're double-quoted.

Now certain of the Windows shell API (and here "shell" means: the visual
elements, *not* the cmd/PS command shell) will only operate on
backslash-separated paths. For example: SHILCreateFromPath:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb762210(v=vs.85).aspx

I'm not exactly how much that affects the current discussion, but my
point is that there *are* places in Windows where the backslash is the
only acceptable separator.

Changing os.sep globally is real no-no. it has the potential to break a
*lot* of code and we're in no position to assess how it's been used.
Applying a change conditionally might be acceptable, but somone would
have to work out how we knew what environment we were in.

TJG