Why we choose Only Python not other for scripting in FME?
Best answer by takashi
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+22- Safer
Â
Â
That said, you can use Tcl in FME in pretty much the same ways as you can use Python. Tcl was popular when we first began developing FME and plays an important role in FME, but it has a number of shortcomings that Python addresses, not the least of which is that it is far less popular and so there is less knowledge about it in general.Â
Â
We have a JavascriptCaller as well, but at this point it is far less capable than our Python and Tcl integrations.
Â
Â
Personally, I prefer Python to both Tcl and Javascript because of, among other things, legibility, ease of development, tight integration with the FME engine and the abundance of built-in modules that are already included in the Python distribution.Â
Â
DavidÂ
Â
- Best Answer
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
That's an interesting point. We also get into these issues here in Europe with some accents, and it's true that it can be a pain. However, I've found that if I cast all strings to unicode before processing it is rather straight forward. Concerning the FMELogFile() class, I've created a small wrapper around it that converts back to the local character set when necessary.
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
In fact, there is another Japanese specific issue other than the 'unicode'. The default encoding of Windows Japanese edition is called "cp932". In the code set, a Japanese character is represented by 2 bytes. The worse, there are some characters containing 0x5C (backslash) as the second byte. As you know, the backslash escapes the next character, so it causes some troubles if you write a string literal or regular expression containing such a character. It seems to be involved in Python interpreter, Tcl doesn't have this issue. It's also a reason that I use Tcl for string operations.
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
In passing, I know that the issue I mentioned above can be avoided by putting a coding declaration on the top of the Python script. However, the script may not be run on other platform (e.g. Linux) any longer. I don't want that.
In fact, there is another Japanese specific issue other than the 'unicode'. The default encoding of Windows Japanese edition is called "cp932". In the code set, a Japanese character is represented by 2 bytes. The worse, there are some characters containing 0x5C (backslash) as the second byte. As you know, the backslash escapes the next character, so it causes some troubles if you write a string literal or regular expression containing such a character. It seems to be involved in Python interpreter, Tcl doesn't have this issue. It's also a reason that I use Tcl for string operations.
Interesting, I didn't know it was that bad... I guess that might also be why the Yen-character shows up rather than the backslash on japanese terminals?
Interesting, I didn't know it was that bad... I guess that might also be why the Yen-character shows up rather than the backslash on japanese terminals?
Since the yen-character is a single byte, it doesn't concern to the issue directly. However it becomes a wall separating us from foreign friends sometimes. I always have to add a comment to a screenshot showing yen... Anyway, multi-byte characters ending with 0x5C are so troublesome!
+22- Safer
Â
Â
I frequently use Python on the same reason as David, but also use Tcl when string operations are required primarily. In Japanese locale, I need to think of encoding issues carefully when writing Python scripts to perform string operations. It's really troublesome, although it's not impossible. Tcl is better on this point, I don't need to consider about such encoding issues. Sometimes, therefore, both PythonCaller (manipulating geometries and/or performing math calculations) and TclCaller (performing string operations) exist in the same workspace.Â
Â
TakashiÂ
All the more reason for us to get the unicode Python API completed and integrated. Sorry for the issues in the meantime. A rare area where Tcl, which says it is all in UTF8, has an advantage of Python...
All the more reason for us to get the unicode Python API completed and integrated. Sorry for the issues in the meantime. A rare area where Tcl, which says it is all in UTF8, has an advantage of Python...
I guess that the issue caused by a string literal or regular expression containing "damemoji" (characters having 0x5C as 2nd byte) might be resolved, if the Python script editor of Workbench would encode the user entered script to UTF-8. However, I'm afraid that UTF-8 editor may cause bad side-effects...
+54- Celebrity
Hi all, very interessnt this question. With Python and FME we have a goods results with our clients.
+15- Contributor
I prefer tcl, much more elegant.
Huge libraries. (but so have others)
Big forums. (but so have others)
But do switch to python (now and then). For no apperant reason..just because we can.
Lately messing more with autocad and doing LISP (because fme ACAD writer and Styler are lacking in lots of respects)..talk about legibility..lol.