Undocumented string processing in expressions : shall we document ?
Posted: Sat May 15, 2021 9:23 am
Hi all,
There is a cool feature in expressions about string processing that is, AFAIK, undocumented.
Actually is appears that expressions are able to process strings in the old fashion Python way (% formatting) using the '<< >>' delimiters.
A typical example would be that would return (with a default cube)
Only one specifier is possible inside delimiters, but string concatenating is also possible using '+', and all Python specifiers are available.
So with a default cube and 3 decimals as a precision would expand in
This to me opens a bunch of new possibilities. Obvious one is for part engraving as demonstrated below:
I also attach the file, so you can play with (I used this possibility both in conditional expressions in spreadsheet, and in the text of the shapestring) -- you may have to set the font path in the shapestring so file works --.
Now the question is : can it be considered as a really consciously coded feature that we will maintain, and so we can document ? Or is this just an unexpected side effect of the expression engine parser that we are absolutely not sure it will work again in the future (so better not document) ?
Anyway, great kudos to @Forthman that bring this possibility into the light :
There is a cool feature in expressions about string processing that is, AFAIK, undocumented.
Actually is appears that expressions are able to process strings in the old fashion Python way (% formatting) using the '<< >>' delimiters.
A typical example would be
Code: Select all
<<The length of the cube is : %s>> % Box.Length
Code: Select all
The length of the cube is : 10.0 mm
So with a default cube and 3 decimals as a precision
Code: Select all
<<Box (%s) : >> % Box.Label + <<L = %g mm : >> % Box.Length + <<W = %.2f mm>> % Box.Width
Code: Select all
Box (Cube) : L = 10 mm : W = 10.00 mm
Now the question is : can it be considered as a really consciously coded feature that we will maintain, and so we can document ? Or is this just an unexpected side effect of the expression engine parser that we are absolutely not sure it will work again in the future (so better not document) ?
Anyway, great kudos to @Forthman that bring this possibility into the light :