Node to Node attr links pass str instead of python objects

[chrisdreid]

I am having an issue where the piped value of a node attr to another node attr gets represented as a string.
I am using Python 3.7.9 (tags/v3.7.9:13c94747c7, Aug 17 2020, 18:58:18) on Windows10

I mocked up a simple example and would like to understand how I can access the object from node->node2 without using global layer value.
pass_str_issue_01.zip

In this example, data is flowing from a layer variable through the piped node attributes:
Layer.simple_obj -> node.obj_container -> node2.obj_distal

This is the output in console:

Layer: -> layer:s00_test
 Node: layer:s00_test
 Node2: Type:[<class 'str'>]  *<SimpleObject object at 0x0000022245EF2548>*

Thanks,

Chris

[ImLucasBrown]

Hey @chrisdreid, great question!
I think you may have uncovered an inconsistency in how tokens work. We've been talking internally about changing some of the tooling around when/how tokens resolve. Your issue is definitely related.

In any case I can offer you this workaround:
original

print(' Node2: Type:[%s]  *%s*'%(type(self.obj_distal),self.obj_distal))

workaround

print(' Node2: Type:[%s]  *%s*'%(type(${/node.obj_container}),${/node.obj_container}))

Basically if you resolve the token in the code block it should return the real object. This assumes the token is pointing to a node that has already been executed.

Hopefully this is helpful to you. We'll continue to talk about this internally.

[chrisdreid]

Thanks @ImLucasBrown ,

I have tested both of these methods.

This with pipe disconnected:

print(' Node2: Type:[%s]  *%s*'%(type(${/node.obj_container}),${/node.obj_container}))

result:

GRAPH ERROR: File "C:/Users/<username>/nxt/pass_str_issue_01.nxt", line 4, in /node2
    print(' Node2: Type:[%s]  *%s*'%(type(),))
TypeError: type() takes 1 or 3 arguments

and

This with pipe connected: (edited : code is now right)

print(' Node2: Type:[%s]  *%s*'%(type(${obj_distal}),${obj_distal}))

result:

GRAPH ERROR: File "C:/Users/Chris/nxt/pass_str_issue_01.nxt", line 3, in /node2
    print(' Node2: Type:[%s]  *%s*'%(type(),))
                                          ^
SyntaxError: invalid syntax

[ImLucasBrown]

My mistake, I kinda rushed that reply.
Only primitive python objects can be passed through tokens. If you want to pass objects around who's __repr__ isn't "perfect" you'll need to use the STAGE object.
The STAGE object is actually the layer node (the one that you do you imports in), it is the only directly accessible node.

I made a few edits to your example and attached them (strip the.txt before you drag and drop it in)
pass_str_issue_01_fix.nxt.txt

[chrisdreid]

Thanks for the info,

Is this by design or are there plans on passing python objects in the future?

[ImLucasBrown]

This is by design yes. Essentially tokens are just fancy string substitution. We have plans to change when we resolve tokens, but not how.
We're open to extending the feature set though. Given a spec of how something should work we'd consider it.

[MichaelAldrich]

Wanted to jump in and talk design for a second, I hope I can contextualize why resolve behaves like it does, and how to build with it in mind.

Built in python types tend to have "perfect __repr__", Which is where it's string-converted representation will eval back into the object(This is documented behaviour). When substituting attr values in nxt, via ${}, built in python types work out of the box: like str, int, float, and even collections of builtin types types like list and dict.

Nxt's substitution is built to be able to resolve into something that gives users a better since of intent when changing inputs to a script, to show them ahead of time how their value will be used, because we "resolve" that into a string before each node's execution, we need each object to be represented as a string.

When you need to pass a rich python object, the STAGE keyword is our designed pathway for passing python objects between nodes within a graph. As Lucas said, the STAGE keyword is really a link directly to the world node, you can see the results of this in the cached view when the world node is selected(double click a layer name in layer manager)

If you wanted to build a library to have it's objects substituted freely in nxt, you can implement __repr__ for the relevant classes in order for them to be able to eval into themselves when substituted. For instance:

class CerealToday(object):
    def __init__(self, number, word):
    self.num = number
    self.word = word

    def __repr__(self):
        return r"CerealToday({}, '{}')".format(self.num, self.word)

This will substitute a creation of a new python object, "Perfectly" the same as the original, into the script when the object is encountered as an attribute value during runtime substitution. Attached is a demo graph using this technique.

n.b. that it's best for you to define or import this class in your world node, so that each node has access should it be resolved into it.

shredded-wheat.zip

[chrisdreid]

Thanks for the info @MichaelAldrich

So are you saying that NXT resolves by doing an eval( obj.__repr__() ) and if that fails then it returns the obj.__repr__() as a string?

WIth your explanation I can see a nice way to move any object through pipes with tokens regardless of correct __repr__.
I will test it out later this week. Maybe we can incorporate it into nxt backend.

What is the difference between how ${my_token} and self.my_token evaluate?

[ImLucasBrown]

I think I can shed a little more detailed light on the resolve logic and hopefully answer your question.

Before execution, what we call editor time, all attributes are just strings.
Immediately before a node is executed we loop over the node's user created attributes via dir() (this will include inherited attributes from ancestors and instances).
We apply some heuristics to the attribute value which you can see here.
If the attribute type is determined to be a primitive Python type we call eval(attr_value).
The result of the eval is the resolved value, we push that resolved value back to the node via a setAttr.
Next we resolve the tokens in the code block by simply substituting the token string for the value they're calling via a getAttr.
After the node finishes running its code block we check to see if the user modified any attributes via the self key word.
If the user did modify an attribute (even an inherited one) we push the modified value back to the real comp node so dependent nodes will get the new value.
Its a bit complicated to explain, but we hold on to an unaltered copy of the node we're executing.

A self.attr call (for now) is simply a getAttr call on the node that is executing. Since we resolve tokens before the code block runs it will return the value that was resolved before execution started (unless the user mutated the value previously).

Resolve is a complicated subject, but hopefully that made sense.