Create a path class in VisIt to handle path strings internally always as unix-style

[brugger1]

Describe the bug

I tried to open a file on Windows and the obvious failed and I had to replace all the slashes with double slashes. This seems really unintuitive. Here is what I tried.

Desktop

• OS and version: Windows
• VisIt Version: 3.1.1

[biagas]

This is the case for most everything we do with paths via python on Windows.

[markcmiller86]

I believe Python itself has best practices and modules for dealing with this in an OS/file system agnostic sort of way.

Can we maybe either define/document a best practice in the use of existing python modules to deal with file system paths in an OS agnostic way or maybe create a path utility python function that allows VisIt python code to be easily (maybe more easily than using existing python module functionality) developed, maintained and moved between platforms.

[brugger1]

It just seems like there are a lot of gotchas to using VisIt on Windows and this is another example that we should try to make better, or at a minimum document. Even when using the GUI this type of stuff sometimes leaks in because we are using Python under the covers.

[markcmiller86]

gotchas to using VisIt on Windows

FWIW...I think these are less specific to VisIt and more related to Python and OS portability in Python itself.

IMHO, this is a common issue in Python. So much so, Python does have modules and best practices for handling it. For example, use the os.path module. But, if one is not accustomed to using those modules in their python code to handle strings related to file system paths, it is a bit of a shock to realize it is necessary.

[markcmiller86]

I guess its concievable we could add logic wherever a user passes a string representing a path to a VisIt CLI function to do the right thing with that string in terms of interpreting things like C: and slash characters. I dunno how involved that would be and how good a result we could achieve doing that.

In the VisIt test suite, we handle this the pythonic way (well, @cyrush did when he overhauled our scripting to go 100% python)

[brugger1]

Yes, that might be a good idea. Another thing about my specific use case, I thought I was using the windows path separator and since the path was quoted, spaces should be ok. Using os.path.join() would probably also have done it, but seems harder than it should be.

[biagas]

Problem with Windows-style separators are the fact that they are escape characters, hence the need to use '\\' in strings.

Python 3 has pathlib which should be helpful.

Overall, I think VisIt should also use some sort of Path class so that handling filenames/paths and os-specific conversions can all happen in one place. Store them with forward-slashes so we don't have to worry about the need to escape the path-separator, and have a method to retrieve a windows-style path when needed.

[markcmiller86]

As long as Windows users can write paths naturally for their world and Unix users for their world...I think this makes sense.

That said, I think there are basic problems for Windows case to be natural...

>>> f="This\is\a\path"
>>> f
'This\\is\x07\\path'
>>> f="This\is\one\path"
>>> f
'This\\is\\one\\path'

In the first case, one of the backslashes is interpreted as an escape character on a. In the second case, all backslashes are interperted as backslash characters. So, without creating our own Path object (maybe that is what @biagas was suggesting), I don't see how we fix this problem, apart from the others already mentioned.

[cyrush]

Do python raw strings help:

f=r"This\is\a\path"

?

[markcmiller86]

Oh, good idea...and yes they do...

>>> f=r"this\is\a\path"
>>> f
'this\\is\\a\\path'

And, BTW...I neglected to mention the bad behavior (e.g. without raw string) occurs in both Python 2 and Python 3. But, the raw string works in both.

[brugger1]

We should create a path class that stores paths internally using unix style but which accepts and presents them in the other manner if the path is intended to represent a path on Windows. This would be a lot of work (many places to touch, especially for string literals) but worth it. Qt has a class that solves this problem, which we could use as basis for our class.