Excellent! Absolute gems in here.
Figured I’d contribute a couple other neat ones I use a lot:
This returns a list of table cells. using [1::] at the end omits the first row, which is useful if that is a header and not usable data.
This gets even better if you are trying to supply a join CHOP for instance with a list of space separated op paths. you can use the above one liner with great success.
If you need the values of those cells as strings for instance, map() is great:
list( map( str , op("someDat").col('columnName')[1::] ) )
Or if you have a table column of op paths, then map can help turn those into op references:
list( map( op , op("someDat").col('columnName')[1::] ) )
Another one that is great - somewhat hard to read, but can be invaluable in a pinch is the one liner for taking a 2 dimensional array and “unraveling” it into a 1 dimensional array:
# traditional double for loop structure: for word in sentence: for character in word: character # Oneliner for double list comprehension. flattenedWordList = [character for word in sentence for character in word]
So many great tricks.
In general, I put anything I write that I think might be useful in TDFunctions, so check this out: https://docs.derivative.ca/TDFunctions
Also want to give specific attention to tdu.split. This function is used to facilitate space separated lists in string parameters. It returns a list of the items in the string, and obeys quotes. So: tdu.split(‘a b c “d e”’) returns [‘a’, ‘b’, ‘c’, ‘d e’]
Super useful if you want to put a list of items in a custom string parameter.
Oh yeah, the whole [:1] [1:] [-1] structure is def worth an entry!
The mapping ones also look really intriging, esp the map to op might be incredible usefull!
In all thinking if this should be a series of posts or if I should edit new ones into the main post.
Im currently more leaning towards a series with small peaces for better digestion.
What do you think?
ya for sure! series or single, not sure - maybe if multiple can just cross link between them so anyone who stumbles on one can find the rest in the series? This is seriously a great topic. great idea you had here.
some link in every entry pointing to the prevoius and the next entry. Should be doable
Thanks for nice tricks
I would like to ask whether it wouldn’t be better to just use
op('opname').pars('parname') instead of those has/get/set attrs?
Yes, this is not good. No problem to use in simple one off events, but in general not the best solution. You are basicly handpicking a single element out of a list of all the parameter. I suppose this gets slower the more pars you have.
The fastest way is in fact to have the refference stored once and acces the object directly.
Nearly the same is setattr and getting the attribute and setting then the value.
Usinf your equasion sadly bombs completly
Aha, I see. Thank you very much for this performance comparison.
Maybe this kind of functionality could be added in new method so that newcomers could easily find it and use it? I mean it would make sense to be able to do something like
op('opname').getpar('parname') (with essentially the same performance as with getattr).
For example in Houdini one could do the same thing with
hou.node('nodename').parm('parname'). I think it makes the code more clean and readable. What do you think?
In theorie totaly with you here!
I think the fastest would be if the par member could just be a dictionary of all the parameters. Kinda nobrainer that it isn’t … (so it would be op().par[‘Float’]. Floating arround in my head for a while now, gonna open an RFE.
That sounds great, I hope it will be implemented at some point.
Ya agreed, params get expensive when accessing them from scripts in large numbers or real time. Have also gone that route of storing param refs in python storage of some kind, and it does speed things up a lot.
Well, that’s something I love about deriative. One small question can lead to change real quick:
Wow, this is great, I didn’t expect it to be implemented this fast. Thanks!
I’m excited about this too! To be clear, it will be par[‘Parname’] not par[‘Parlabel’]
There will never be an op(‘base’).par[‘MyFloat’]! It would be op(‘base’).par[‘Myfloat’]