Separate patch and node's code in to files

[honix]

Read conversation here #17

[honix]

Oh, shit. This never been that easy.

[honix]

According to 1f3ca76:

• 'O' key will add node pointing to file nodes/identity.py
• 'R' key will reload all nodes

So we get separation. Now let's create a library of nodes! :)

[bilderbuchi]

A question: can you clear up why you use exec() here (and elsewhere in the code) instead of importing the module? Seems to me not very pythonic, and possibly quite the security risk, and I don't see why it is done that way.

[honix]

Pretty pythonic i think, it uses dynamic nature of the lang. Module import may be unsecure too, as i belive it is just a form of exec. Which is parse code and evaluate it in current environment.

How do you see importing using modules? Maybe it can be better for nodes library than exec?

[bilderbuchi]

OK, maybe I have misunderstood what exec should do, sorry. An advantage, in any case, is that you can tweak the scope with the optional arguments of exec().

[drtrigon]

This closes #9 also.

[drtrigon]

@honix: What is the exact idea now? Should nodes only be used as shown be the nodes/identity.py example here? Or is this just one additional way of using it? I wonder as module imports from external python script have to be possible. The also have to work using import. What about putting the call = identity into the pyno node? That would allow to use one .py file for all nodes and come close to #14? (is this a scope issue?) Is the idea to always use the same code for those externals in the pyno node? (sorry for may be aking naiive questions - I try to clarify the concept)

[honix]

@drtrigon there is little trouble with import when i use G and S variables in some nodes, and they are not defined, so import throws exception.

But importing from external modules is possible right now! You just need to call-bind function from module. And you can hold this functions in one file. As @bilderbuchi mentioned:

Really i dont have any exact opinion. It is good that here many ways to do. But we need to choose one 'official' way of importing. I like import example, need to solve scope issue. :)

[honix]

I will reopen this issue to find best way of making node-files. I found this scheme can handle local and (if needed) global scopes. One thing i don't like is pyno code on the right: too many lines. We can introduce new binding node = w.Window as reference of class, or something smarter. :)

[honix]

If we do, this can end up with something like this in pyno. But i find this little long and complicated for users. So i prefer to take call cleanup fast binding alongside with node pro-user binding. Guys?

[bilderbuchi]

I'll have to think on this. But yes, simple/short is good, which is why I elsewhere suggested looking into decorators, this way you can hide complexity from users.

[honix]

Another crazy idea is to link node symbol to node itself, so user can node.call = kill_all_aliens(42) or even node.color = (0, 0, 255). Hackableeee!

By this we reduce 'service' symbols to just node.

[drtrigon]

The class approach reminds me to https://www.vistrails.org/usersguide/dev/html/packages.html

You want to be able to have multiple functions in one node and all the code in a python file. I can think of 2 ways:

• having per node sections in .py file, may be separated by comments, but this needs a parser and you will end up having a file containing severall call = bindings
• the other way would be to put each nodes code into a function (def), that would allow to import the .py as module, then you have one function per node with own scope, can call the code and use inspect to get the source

Generally I think the call binding should may be not be part of the .py file but off the pyno patch onl

The node symbol could most probably be similar to the self we need for loop support.

[bilderbuchi]

OK, I have to admit I don't understand why there is GUI/windows code up there in the user-defined node code. I think you strictly have to separate three things, and then the structure will hopefully be clearer to implement (note I have not read the current code for these things):

• The user-supplied code that defines the operation to run, processing inputs, generating outputs. It should be possible to import foreign function definitions for this, or import/use functions defined in pyno.nodes.* Personally, I would consider not allowing global scope in those functions, as this will just make the design much messier (what did you intend to do with those, anyway?). It's easy with pure functions (and you already have that under control, I think), and a bit trickier for stateful objects.
• The code defining what a node does/is - which function to execute, name of the node, determining inputs/outputs, allow for connections, etc. This will go in a class, and could for example instantiated be used like this:

  somenode = Node(call=numpy.cos)
  somenode = Node(call=pyno.nodes.timeSinus)
  somenode = Node(call=string_from_editor_window)
  somenode.update_call(updated_content_from_editor)

  (By the way, the name .call is kinda dangerous, as it's easy to confuse it with the Python __call__ method. Something like compute or process would proably be clearer.

• all the nodes go in a graph structure (basically a dict of nodes), that defines the connections between the different inputs/outputs, and which can be ordered and each nodes' call method can be executed in turn.
• Last, the Windowing/GUI/representation code - this should not be in the node code at all, but instead consume that to create the visual representation, and will call functions like mygraph[42].update_call(new_content) to interact with the node.

[bilderbuchi]

I just fonud out that PyQtGraph also has something similiar called "flowchart": http://www.pyqtgraph.org/documentation/flowchart/index.html

[drtrigon]

• we will for sure need global variables - LabView has it too even though it is discouraged to use, some things are very simple to solve using globals and close to impossible else - though if used they have to be well documented
• the graph structure is at least a list of dictonnaries, as a single patch can contain an infinite number of unconnected graphs: e.g. graph1 A-B-C, graph2 D-E, etc.