Sloader Posted September 5, 2022 Share Posted September 5, 2022 This line (on its own as a test but also as part of a bigger script) compiles fine LNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\LNR.dxf', isBatch) But if I change the file to NNR.dxf (national and local nature reserves) the script doesn't compile and I get a error as below which makes no sense to me as all I change is an L to an N NNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\NNR.dxf', isBatch) it even works with lower case NNR NNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\nnr.dxf', isBatch) Quote Link to comment
Pat Stanford Posted September 5, 2022 Share Posted September 5, 2022 Definitely a bug. Please submit it. \N is the escaped version of a New Line character. Somehow the parser is not looking at the string as a string, but rather is looking at it as characters and trying to find control characters and is seeing the \N as a bad character in the string. Since VW only runs on Mac and Windows which are both case independent file names, you could convert the file path to lowercase as a work around. Or what happens if you store the string in a variable and use the variable in the ImportDXFDWGFile instead of the string literal? HTH Quote Link to comment
MullinRJ Posted September 5, 2022 Share Posted September 5, 2022 @Sloader, What happens if you escape the "\" character with "\\" so the substring "\\NNR" is interpreted as "\NNR"? I have not tested this, but I've been able to get around things like this in the past. Raymond Quote Link to comment
Pat Stanford Posted September 5, 2022 Share Posted September 5, 2022 I am also curious like @MullinRJ about what happens is you "escape" the slash, but that is a bad work around in a script where you might not know what file path someone is inputting. That will cause you all sorts of extra trouble shooting down the line versus just using lower case and filing a bug on the error. Sorry Raymond, on this one I disagree. 😉 1 Quote Link to comment
MullinRJ Posted September 5, 2022 Share Posted September 5, 2022 All I did was ask a question. I made no statement as to the efficacy or prescription of my suggestion. I am just curious if it would work. If I had wanted to spend the time, I would have setup a test file and a dummy script and tried it myself. It's Labor Day, and I'm resting (sort of). I, like many before me, took the lazy way and posed a question rather than launched an investigation. 😜 (Disagree with me again and I shall twice stick my emoji's tongue in your direction) Happy Labor Day, Raymond PS - I probably could have learned the answer to my query in the time it took me to compose this response. 1 Quote Link to comment
Sloader Posted September 6, 2022 Author Share Posted September 6, 2022 Adding and extra "\" does make the compiler happy but I have already changed the name to "nnr" which works fine, both options seem unnecessary. I was interested if my script is incorrect - I assumed the contents between ' ' would be interpreted as a string LNR = vs.ImportDXFDWGFile('C:\DOCs\SCRIPT\\NNR.dxf', isBatch) Quote Link to comment
Pat Stanford Posted September 6, 2022 Share Posted September 6, 2022 I agree with you. Something like a file name should just be interpreted as a string and accepted directly. Whatever parser they are using under the hood is configured incorrectly IMNSHO. Quote Link to comment
MullinRJ Posted September 6, 2022 Share Posted September 6, 2022 (edited) 1 hour ago, Pat Stanford said: I agree with you. Something like a file name should just be interpreted as a string and accepted directly. Forgive me, @Pat Stanford. I must now disagree with you; respectfully, of course. I believe Python does document the escape character for newline as "\n", being just one of several. Here is a list of the others – Python string escape characters. Once you know all the rules, it's easier to get it right the first time ... but it does cut down on invigorating forum discussions. What I don't understand, all of the escape characters use lower case, so why does "\N" kick an error. Also, after playing around with some dummy strings, I found that "\a" doesn't print but does execute, which makes me believe the referenced list may not be complete at least as far as the VW Python engine is concerned. I suggest for anyone that's interested they test every character with a "\" before it to see what happens when a script is run, and when that string is printed. Raymond 😉 Edited September 6, 2022 by MullinRJ additional input Quote Link to comment
Pat Stanford Posted September 7, 2022 Share Posted September 7, 2022 I still think it is a parser error. Not a bug, but a misapplication of something. Why would the parser be looking for newline characters in a string defining a file path. It is an illegal character. And the path is inside the vs.Import function, so it is probably not a Python parser, but rather something that VW put in (probably didn't write) a long time ago. Quote Link to comment
MullinRJ Posted September 7, 2022 Share Posted September 7, 2022 Hey, Pat. I don't think VW put in that feature. I believe it is a Python feature for all strings. This is not a runtime error. The Python engine is flagging a problem before execution, so it is a syntax error. To look at it another way, how would Python know a string holds a File Pathname? A string is a string is a string, until it is passed to some procedure that tries to use it. It is up to the user to know how to encode strings properly, and not Python's responsibility to know what the user really wants. Basic programming minutiae. The same is true in Pascal when trying to add a single quote to a string, the only difference is Python has more escape characters than Pascal. What I don't understand, why is "/N" flagged as an error when the Python interpreter is looking for "/n"? Maybe a real Python expert could weigh in on this topic. I know just enough to be dangerous, but not necessarily helpful. Raymond Quote Link to comment
Sloader Posted September 8, 2022 Author Share Posted September 8, 2022 It makes little sense to me that the python escape character is /n yet a path with /n works fine whilst a path with /N doesn't. Also I am not sure why it used to work fine on MAC but when transferring my scripts to PC it wouldn't run. Is there a reliable way to include a file path that won't get escaped by python due to any of the special characters ? Quote Link to comment
DomC Posted September 10, 2022 Share Posted September 10, 2022 (edited) Hi I would not say i am a python expert and i also was fighting a lot with path-strings (strings and text encoding generally) in the past. Let python os-module do the job. Allow me to suggest this as following: import os full_absolut_path = os.path.join('c:', 'DOCs', 'SCRIPT', 'NNR.dxf') LNR = vs.ImportDXFDWGFile(full_path, isBatch) #or in one line LNR = vs.ImportDXFDWGFile(os.path.join('c:', 'DOCs', 'SCRIPT', 'NNR.dxf'), isBatch) This would work on both platforms. Also i saw if we are reading path from os and use it as a string, it can be necessary to normalize the path string because of some special characters to make it look good in Vectorworks on both platforms: import unicodedata path_string = unicodedata.normalize('NFC', full_absolut_path) Edit: In my opinion it is just "luck", that \D and \S are no special controls in python. \n creates a new line \N --> No idea, what creates that. Something that is not compatible for unicode decoding. The String is forwarded from python to VW and VW can "parse" the path with some rules but here python itself just can't interpret the code of the programmer. string 'C:\DOCs\SCRIPT\NNR.dxf' is as unallowed as a division by 0 which also put an error on the screen without any further arguments. We could try to push a raw string to the VW function and see what happens. like that: NNR = vs.ImportDXFDWGFile(r'C:\DOCs\SCRIPT\NNR.dxf', isBatch) Edited September 10, 2022 by DomC Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.