ok, just getting into the python stuff today. I'm noticing that there is only a geometry python definition. Does this mean that I can't create a custom CHOP with python?

Yes, that didn't make it into H9. I don't know what are the plans for that though.

ok I'm going to cry now

It seems like the geometry one has to do a lot more than a chop one would. All the chop would have to do would be to access the “ic” … the oc would be a lot more powerful than the expresson chop since you could keep manipulating the channels (essentailly oc) until the desired result was reached with for loops.

Or am I looking at this the wrong way?

is this what I'm referring to?

hou.ChopNode.evaluateInput() and
hou.ChopNode.evaluate()

and it just isn't implemented yet but will be? Also will a python chop type be possible when they are implemented?

As far as I can tell, they haven't been implemented. Implementing those doesn't necessarily mean a python chop type since one can call HOM functions from anywhere python can be used. Of course, a python chop type will probably need those functions.

I see, so I guess if they implement those you wouldn't really need a “python chop” it could be any DA with python script running those functions?

Well, running python scripts isn't quite the same as using python scripts to generate your node's output. I suppose there could always be workarounds though but likely very ugly ones.

o ok,

well I hope they implement a CHOP type .. it was just my impression from all the 9 promo, but I was expecting python was going to be “superior / replacing” the other languages etc.

Looks like it's still the expression CHOP for a while then. It's just very difficult to manage channel logic intelligently with the expression CHOP. Other pre-cursor channels usually need to be generated just to tell the expression CHOP what to do, the ability to use variables, and for-loops with nested if-statements would solve this problem and use memory MUCH more efficiently.