Python API breaks when evaluating certain lowercase tags about mdsplus HOT 9 OPEN

The escape character processing is an inherent feature of Python strings. As is illustrated by this example.

>>> str1="\Tz"
>>> len(str1)
3
>>> 
>>> str2="\tz"
>>> len(str2)
2
>>> 
>>> str3=r"\tz"
>>> len(str3)
3
>>> 
>>> str4="\\tz"
>>> len(str4)
3

And the solution is as described at the end of the initial bug report, namely to use an additional backslash or to use a raw string.

from mdsplus.

Some ideas for consideration . . .

• Update the documentation on the mdsplus.org web site regarding use of tabs (\t) and other special characters in node names / paths passed to the Python API.

• Improve error handling to check for the common special characters in node paths. Because MDSplus uses a backslash to indicate a tag (e.g., \TOP, \NEW_CALC), when users type those tags in lower case it will be easy to unintentionally create typos (e.g. \top starts with a tab, and \new_calc starts with a new-line).

• Not recommended, but it would also be possible for the Python API to detect special characters and convert them back to the two-character mnemonic (e.g, tab is converted to \t).

from mdsplus.

For a tool we've been developing internally I just have a line that converts the input string to uppercase (it wants the treenames to be capitalized for some reason, might actually be a related bug come to think of it).

from mdsplus.

The issue is that uppercasing <tab>something merely makes it <tab>SOMETHING. As is shown in the following example.

>>> str5 = '\tz'
>>> len(str5)
2

>>> str6 = str5.upper()
>>> str6
'\tZ'
>>> len(str6)
2

To avoid having a <tab> in a string, one must either . . .

• not type Python strings that contain tabs (i.e., the \t sequence), or
• have code that scans input strings for special characters and replaces them with two characters (i.e., building up the "raw" string that is equivalent to the user's supposed intent)

from mdsplus.

Ahh, I should have thought of that. Didn't realize the string object got created in memory when it got passed into a function, but it makes sense. My hope was to make it simpler to potentially do preprocessing, but it looks like realistically the outcome here is that while normal MDSplus is not case sensitive, the python API just needs all caps.

from mdsplus.

Hi @ModestMC,

Correct. Users should either use uppercase, raw strings, or double-backslash of special characters (such as \\t instead of \t) when entering Python strings that are passed to the Python API for MDSplus.

We could probably add some documentation to the mdsplus.org Wiki if you wish. However, adding a feature to the Python API to scan for special characters would likely be a low priority (e.g., expanding the coverage of the test suite likely is more important).

Should I close this issue?

from mdsplus.

I think the issue is fine to close.

If you can point me at where in the API the preprocessing would need to live, I can see about potentially adding some string preprocessing to fix the input (at least when TDI is attempting to be evaluated). Even then, this issue could be closed as some kind of tech debt/won't fix/etc. Would that be helpful?

from mdsplus.

Hi @ModestMC,

Thanks for your input. I'll look at the code and get back to you. (And I am also inclined to add a few sentences to the mdsplus.org web site explaining the issue with Python strings.)

from mdsplus.