Add a Terminal/Console/Shell

[00-0o]

I come with a feature request, a suggestion, perhaps is already implemented and i'm not aware.
Feel free to move this ticket if is not in the right place.
So i come with a request for something i already solved somehow for myself but it's perhaps useful to other users.
And probably can be better implemented from developers side than what i did.
I modified the "main.py" of nodezator to launch an ipython console to debug and "directly" interact with the nodes.
It runs nodezator it makes nodezator to run in it's own thread normally but exposing it's runtime variables and functions to the main execution.
Here is what i did, hope it's useful to someone.

This first file is in the directory where you nodezator is installed, normally in the site packages of your python environment.

You have to rename it as .py , back up (just in case) and replace the original file.
you dont have to actually rename it just change the .txt to .py github does not recognize the underscore that's why in added the nodezator-to__main__.py to diffrenciate it from the other file
nodezator__main__.py"

this other file you just run your ide or anywhere where it can import from nodezator.
it will launch nodezator normally but without blocking your terminal and giving you an ipython shell.
You'll need to pip install ipython if not installed on your environment.
main.py
Once it runs, you can do dir(ndz) to see whats doing on. and dir(ndz.APP_REFS)
If you are using pycharm i recommend to run in debug mode to have autocompletion and access to your file system as well ;)

I'm not a very tec guy so, perhaps is a dumb thing, but i hope someone find it useful.

[KennedyRichard]

I assume you are elotero from Discord. Again, thank you for the discussions. Just stopping by to remember you that I'll check and answer to them properly at the beginning of the week, as I said on Discord.

I just wanted to reassure you of that since I just replied to another discussion here ahead of yours. Only did that because I deemed it more urgent since that discussion was related to a bad experience a new user had and I wanted to guarantee every concern was addressed properly.

Have a nice weekend!

[00-0o]

Hey Kennedy, yes i'm elotero, don't worry buddy take it easy.
I took a glance at the discussions, and for what i read also in discord ppl don't get how easy to use is nodezator, it took me half an hour to understand that i needed two levels of folders to create a node pack.

I think you should make a different video to introduce nodezator.
Instead of showing the cool side, just a video demonstrating the process of making a node, the print("Hello Ndz World") example.

By the way i'm getting a hang on working in ndz, and the codebase, but i'm still lost on how to make a socket not hide the text when linked. It might applies to all display nodes. I think i know what you might have though, (having to update the socket on_linked), i think a timed soft update could do the trick.
Anyway have a good weekend too.

Ahh almost forgot, i read that widgets can be exported as text to see the full code, tell me how, all hints are handy.
(y)

[KennedyRichard]

Sorry for taking so long to reply to this one.

I think you should make a different video to introduce nodezator.
Instead of showing the cool side, just a video demonstrating the process of making a node, the print("Hello Ndz World") example.

I intend to make that video you mentioned. Been wanting to do that for quite some time actually. But first I'll make a much shorter, couple of minutes video teaching people how to create and load their nodes. This should be enough to solve most of the problems newcomers have.

...i'm still lost on how to make a socket not hide the text when linked. It might applies to all display nodes. I think i know what you might have though, (having to update the socket on_linked), i think a timed soft update could do the trick.

Sorry, I don't understand what you meant. Could you provide more context and details, please?

When a node is in expanded mode, when an input socket socket receives a connection, it causes an existing widget (if it has one) to be hidden.

When a node is in collapsed mode, only input sockets with connections are shown.

This is the only behaviour available. If you want to change that, then you'd have to go through a series of modules representing different services for different kinds of nodes (since some kinds of nodes have different behaviours) and make sure all the changes are in synergy so nothing breaks.

Not even I can properly list such modules off the top of my head, as Nodezator's source is quite large. Despite the size, though, I don't actually have much problem implementing changes/fixing things, as I'm quite familiar with the source. It is nothing to be ashamed of, as even the Python's creator (Guido) has to read documentation from time to time.

Nodezator's source is in much need of refactoring in several parts, specially the most recent ones, but it isn't so bad that I can't find my way around. I know this seems like something that should be a given, but believe me, I've seen developers in the past that couldn't even make sense of what they had written or even worse, developers who couldn't even stand having to make changes in their own source. That's how bad some source code can get.

Thankfully, Nodezator is not that bad. However, given its size and number of services, changes like the one you intend to do require a non-trivial amount of time and effort.

I'm just telling you all of that in order not to discourage you. Many things are possible, but a lot of them require a non-trivial amount of work though.

I'd also like to add a few things below, though. I know you are aware of most or all of them, but I'd like to make sure your expectations are set properly regarding this project, so pardon me if I'm being repetitive.

As you must know already, Nodezator is an application, rather than a framework, so it doesn't have exposed APIs for developers to change the behaviour of its nodes/graph. This is stated in the README as well:

What Nodezator is NOT: Nodezator is NOT a framework, which means you can't use it to create your own node-based interface.

In other words, this kind of change you expect to be able to do, makes more sense when talking about frameworks, since they are meant to provide the tools for people to make their own versions of a specific tool, in this case a node editor. The case with Nodezator is different. Since it is not a framework, but rather a full-fledged application, it already has its own way of doing things.

However, I'm not trying to discourage you, just helping you to understand what Nodezator is meant to be, so you can set your expectations accordingly. That is, many of the changes you may want to make may not have easy mechanisms available to implement them, so they will likely require a non-trivial amount of time and effort.

That's because Nodezator was made to achieve specific things in specific ways rather than expose the settings to users like a framework would do.

That said, I'm here to help as much as I can, so please, just give me more details on what exactly you want to achieve and I'll help as best as I can.

Ahh almost forgot, i read that widgets can be exported as text to see the full code, tell me how, all hints are handy.
(y)

That might not be exactly what you read. Or rather, I'm not aware of such possibility. However, since widgets are simply special values added to a function's signature, all you need to know how a widget was set in a parameter is to check the source of that node, which you can do by selecting a node and pressing the i key.

For instance, the mix_images node from the pillow example node pack has an option menu widget in the operation_name parameter:

So if I wanted to see how to define such widget I'd just need to select it and press i, which would display its source:

### third-party imports

from PIL.Image import Image

from PIL.ImageChops import (
                      add,
                      darker,
                      difference,
                      lighter,
                      multiply,
                      soft_light,
                      hard_light,
                      overlay,
                      screen,
                      subtract,
                    )


BLEND_OPERATION_MAP = {
  'add'             : add,
  'darker'          : darker,
  'difference'      : difference,
  'lighter'         : lighter,
  'multiply'        : multiply,
  'soft_light'      : soft_light,
  'hard_light'      : hard_light,
  'overlay'         : overlay,
  'screen'          : screen,
  'subtract'        : subtract,
}


def mix_images(
      
      image1: Image,

      image2: Image,
      
      operation_name : {
        'widget_name': 'option_menu',
        'widget_kwargs': {
          'options': tuple(BLEND_OPERATION_MAP),
        },
        'type': str,
      } = 'multiply',

    ) -> [
      {'name': 'image', 'type': Image},
    ]:
    """"""
    operation = BLEND_OPERATION_MAP[operation_name]
    return operation(image1, image2)

main_callable = mix_images

There, where the operation_name parameter is defined, I can see how the option menu widget is defined:

      operation_name : {
        'widget_name': 'option_menu',
        'widget_kwargs': {
          'options': tuple(BLEND_OPERATION_MAP),
        },
        'type': str,
      } = 'multiply',

Or just check the source file in your disk as well.

Of course, you can learn about such configurations on the manual as well: https://manual.nodezator.com/appendix-widget-configurations.html

Some of those configurations have shorter forms that can be learned here: https://manual.nodezator.com/appendix-widget-presets.html

For instance, to specify a text display widget, instead of using {"widget_name": "text_display", "type": str} as the type hint you can simply use "text".

[00-0o]

Hey Kennedy, nice to read from you.

I intend to make that video you mentioned. Been wanting to do that for quite some time actually. But first I'll make a much shorter, couple of minutes video teaching people how to create and load their nodes. This should be enough to solve most of the problems newcomers have.

This ^ is exactly what i mean by this. ->

I think you should make a different video to introduce nodezator.
Instead of showing the cool side, just a video demonstrating the process of making a node, the print("Hello Ndz World") example.

About the nodes collapsing, better if i show you what i was aiming for.
I wanted to make a tool for creating branching dialogs pretty much like this:

In the first minute of any of the videos you'll get the point.
https://www.youtube.com/watch?v=oRHl2PLKwfY
https://www.youtube.com/watch?v=u9WFmMY5oyY

Coincidentally from a non related game company Obsidian Entertainment, that have nothing to do with obsidian (the note taking app), cool software when having to write large dialogs for point and click games or rpgs, etc.
This is a proprietary software, not available to the public.

There are some similar software around but non was what i was looking for, some are paid, some did'nt export to json but html or xml. There's a very cool, named "Arrow", that export to json. Very cool, but it would force the workflow to a standard i wasn't comfortable with.

So after searching a while i decided to make my own tool, nodezator was the first that came to my mind, but the "collapse" when linked thing, make reading and editing node "content" not ideal.
I wanted to modify modezator, but i the end i was easier to write a few plugins for obsidian (note taking app).

I really appreciate the time you took to write and show me plausible approaches, but since i ended up doing the branching dialog system on top of the Obsidian (note taking app) Canvas, which saves as json, there i was able to define my rules on the python side... So... you can forget about the Collapsing thing.

Is now up and running, i'm still refining it, but it is already usable.
There i can branch dialogs based on conditions, and "action types" based on node shapes and arrow types and variables.

Thanks for all the support!

However, since widgets are simply special values added to a function's signature, all you need to know how a widget was set in a parameter is to check the source of that node, which you can do by selecting a node and pressing the i key.

This ^ might be what i meant by this ->

Ahh almost forgot, i read that widgets can be exported as text to see the full code, tell me how, all hints are handy.

Indeed useful, thanks for the clue!!

I will continue to use nodezator every time i find a suitable task for it, and i'll be involved as much as i can in the community, even while not using nodezator to my dialog system, i really like the indie project, which leads to the next point.

i will jump there to avoid mixing "non related" ideas. here: IndiePython/myappmaker-sdd#1
I've read the myAppMaker thread, a bit today.
I think i have a good idea to leverage the knowledge you already gathered on node based systems...
I'll continue on the other thread.

[KennedyRichard]

Finally got time to take a look into your post!

First of all, thank you for your code contribution!

Addressing a few of your comments

perhaps is a dumb thing, but i hope someone find it useful.

There is no such thing as a dumb contribution. Of course, we all have shortcomings, so at the end of the day a code contribution may indeed be or not be suitable for integration into the project's source, but that doesn't change its intrinsic worth a bit. That is, even if in the end the code isn't used, there are several other elements in that process that may help us in the end.

For instance, the ideas/expectations/beliefs/assumptions that originated that code may provide insight into other future improvements to the project. The code may even be used in other parts or for other purposes.

Besides, even when the code is of high-quality and well-thought-out, it may still not be integrated into the repository simply because it doesn't fit the design/scope/purposes of the project.

I'm not a very tec guy...

Again, don't worry about that, it is not a requirement to contribute code or sharing ideas. However, it is indeed important to be upfront about one's skills and shortcomings, so that everyone can set their expectations accordingly and be able to cooperate more efficiently.

Additionally, there is no minimum level of skill for contributing code/ideas here. Someone with a month of coding can help someone with a week of coding, who can help someone with a week of coding and so forth. Also, even if someone has more experience than others, doesn't mean that experience applies to the same things. Someone with 10 years of programming can still lack knowledge and practice in a specific area in which another programmer with only 01 years of experience may excel.

A bit of context on non-sequential execution paradigms

Now, allow me to give you a bit of context regarding threads and other non-sequential execution paradigms in Nodezator. After that I'll comment on your code contribution.

First of all, I have been studying threads, multiprocessing and other non-synchronous execution paradigms in the past couple of years. Not much though, but on and off when I get a bit of time. That's cause the changes I'm planning for Nodezator as well as several of its features to be implemented are dependent on my knowledge of these paradigms. Even so, I can't focus on that yet because Nodezator still lacks other higher-priority features like group nodes and the missing test cases for the system testing feature, for instance (just to name a few), which are things on which I've been focusing my time.

Because of that, I was only ever able to experiment with more simple and small-scoped examples, which are typical in learning materials for these subjects. To make matters even more complicated, the kind of non-sequential execution that Nodezator requires is much, much more complex than that presented in books and other learning/research materials.

For instance, nodes represent callables, but a callable may be the kind that involves I/O or network-bound operations, for which threads are suitable. However, if the callable involves CPU-bound operations, multiprocessing is better suited. There's also async/coroutines, right? It means in theory Nodezator must be able to handle multiple non-synchronous paradigms to be able properly and efficiently address efficient execution of its graphs.

And the complexity doesn't stop there. Nodezator is a meta-application, that is, it doesn't have a specific purpose, but rather loads and runs code from others for their specific purposes. This means that on top of being able to handle multiple non-sequential execution paradigms, Nodezator needs a way to tell which kind of paradigm is better suited for each given callable. Should we parse/analyse the code? Should we simply allow users to tell us via a specific variable?

Unfortunately, it looks like no book author was ever crazy enough to consider approaches that address the need to mix these and other paradigms, specially in a context where the callables received are arbitrary, that is, the users can provide any number of callables of any kind they want.

Analyzing the source of other existing node editor projects, Python-based or not, may not even provide a direct solution to the problem (although, of course, may allow us to collect useful insights to help with that task), because many of them either provide a limited set of nodes and can thus optimize their execution to suit these operations or simply operate in a scope smaller than that of Nodezator.

That is, on top of allowing the users to provide any kind of callable they want, Nodezator is meant to be a visual representation of Python, which is why one of our proud features is the possibility to export any graph as Python code. This means the Python code exported must also run with mixed non-sequential execution paradigms.

Your code contribution

Now that you know all of that I can finally comment on your code!

Being completely honest, your code looks like great, simple and clever usage of threading. Small solutions like that which provide a lot of new functionality are invaluable. It might not even need any refactoring or other refinements.

The only reason I don't intend to integrate it right now is simply because, as I said before, I must first consider how all the non-sequential execution paradigms will play together within Nodezator.

In other words, I don't know if in the future I'll have to start Nodezator in another thread, or just execute the graph in another thread, or just create execution pools for threads and processes for different kinds of callables to use during execution. I know how to use many of these tools in isolation and there's a lot of learning materials for that freely available, but the problem lies in having to consider them all together within Nodezator.

It is not even that your solution isn't appropriate as far as its purpose is concerned, it is just that I don't have the knowledge, skills and experience enough to properly assess such suitability. And in addition to that, as I already pointed out, finding this out will likely require much research on my part when it is time to implement non-sequential execution. For now, as I said before, I need to focus my time on other features of higher priority and that are also important.

Another point to consider is whether, despite being undoubtedly useful, we would indeed want to include in Nodezator's design the ability to run a console at all. But to be honest, if we can get a console with such minimal code, why not, right? Since a big part of the target users of Nodezator are programmers anyway, then there must indeed be a lot of people that would benefit from it one way or another. We could even use part of your code for using the terminal running Nodezator as the console itself, or provide a console panel within Nodezator as well. Therefore, I'm just mentioning this point for the sake of completion.

What indeed prevents me from integrating this solution is, as I said before, the need to give much more consideration to the different non-sequential execution paradigms Nodezator needs to deal with, coupled with my current inability to properly assess the solution in regard to that.

Regardless of all that though, your solution is very interesting and other people may need it as well, so I'll leave this discussion open. In addition to that, your code may be used in the future, though, once I'm able to properly assess and integrate it. If it ends up being the case, I'll either ask you to submit a PR or I'll commit the changes myself with you (that is, your GitHub profile) as the author of the changes (something that is not only possible, but quite easy to do in git, and something that I did before, with proper permission from the author, of course).

I believe this is all I wanted to say for now. Let me know if you need anything else.

I intend to answer your other discussion post soon as well, and your other comment made on this discussion regarding your suggestion of making another video tutorial for Nodezator. It might take a few hours or a couple of days though, because of other commitments that I need to attend to in the meantime.

Have a nice week!

Peace

[00-0o]

Hey Kennedy, good to read from you, as always well articulated and thoughtful.
Sorry for the late reply i was busy last few days.

I can see you have very valid points in here, i agree with this idea to not be implemented without being carefully measured.
Nodezator is indeed a complex fit for an "all in one" solution to every programing paradigm, and being python one of the biggest general purpose programing languages, there's a lot to take into account about the user approaches and use cases.

With that said, i think that if anyone need's a console in the way i needed (to investigate internal structure of the software), this is an easy solution that does not affect the general functioning of Nodezator in any way, it's just a launcher.
So it could be refactored and added as a flag to the actual launcher of Nodezator, or be refactored to become a real feature.
But feel free to do whatever you want with the idea, i came up with it because i needed to understand how Nodezartor works under the hood.
It might be just a guide line to someone else with the same practical need.

As you said, make the console running Nodezator to be the console, or to have a console within Nodezator, opens a lot of opportunities for debugging and integration. One way or another it widens the scope of the software and makes it more flexible.
(And it would be awesome to have a console panel in the bottom of the screen "x)"!! )

Now about this other approaches to concurrency, async, subprocess, etc i wanted to ask you:
When i though about the terminal, i tried to run the Ipython terminal from a node, then i discovered that i had no access to the other nodes "in the scope", i don't remember exactly, but that's why i decided to make this launcher.

So my question is: how does Nodezator handle this, is every node in it's own subprocess? no, I checked and did not found more python instances running, other than the mine and the Nodezator main. Why is that?

Obviously you have some sort of concurrency with all the nodes.
How do you handle the main_callables to run independently but yet pass the output an inputs. (hmmm i think i know it now) it sparked as i was writing. Nodezator kind of import the node functions and runs them from a single process/pyfile?

This bugged me, i wasn't able to think around this, and i still can't. I had to run a small local server where all the nodes are the clients, to give the nodes some sort of a clue about which node is which.
This is because i need access to node id and data they hold, other than their inner main_calls, for what i'm doing with nodezator, i use nodes as data holders and visual representations. So my nodes are basically the same node 50 times.

About this "questions"
"Should we parse/analyse the code? Should we simply allow users to tell us via a specific variable?"
Some thoughts:
Most of Nodezator and python users in general, don't use co-routines intensively, so even when i think Nodezator might benefit from "parse/analyse" even more, this will involve probably lot of meticulous planning and might end not even feasible due to edge cases, and meta-code that will make your parser writing a nightmare. (Nested code will drive you crazy)
I guess "advanced" users such co-routiners and threaders will be well enough programmers to understand software complexity, and willingly pass a flag variable to clarify the concurrency solving specifics that should be expected.

Is great to see that you give to ideas great consideration and value, i'm glad to know that humble contributions like this might make it to the codebase of Nodezator or just be keept on sight for others to improve and build on top.

Well this is getting too loong already, i read your comments on Run Single Nodes, great to know it might be implemented, i'll comment on that later separately.

Have a great week!!!

[KennedyRichard]

With that said, i think that if anyone need's a console in the way i needed (to investigate internal structure of the software), this is an easy solution that does not affect the general functioning of Nodezator in any way, it's just a launcher.
So it could be refactored and added as a flag to the actual launcher of Nodezator, or be refactored to become a real feature.
But feel free to do whatever you want with the idea, i came up with it because i needed to understand how Nodezartor works under the hood.
It might be just a guide line to someone else with the same practical need.

As you said, make the console running Nodezator to be the console, or to have a console within Nodezator, opens a lot of opportunities for debugging and integration. One way or another it widens the scope of the software and makes it more flexible.
(And it would be awesome to have a console panel in the bottom of the screen "x)"!! )

Yes, I'm considering all of that. I just need time to assess the possibilities. Even simple things that don't interfere with others must only be added after proper thought, with each feature comes usage and with usage comes familiarity, which makes it more hard or just annoying to user when it is changed.

Mostly, I need to check and understand inner workings and implications of running the app or parts of it in another thread. I'll probably end up using 80 to 90% of your original solution, though. Also, for now, I don't have a timeline for this, as it is not an urgent task nor a much requested feature. As you said, I'll leave it here for others that may need a similar solution.

However, since it is a very small change, I'll see if I can indeed include it in a patch in the future.

Now about this other approaches to concurrency, async, subprocess, etc i wanted to ask you:
When i though about the terminal, i tried to run the Ipython terminal from a node, then i discovered that i had no access to the other nodes "in the scope", i don't remember exactly, but that's why i decided to make this launcher.

So my question is: how does Nodezator handle this, is every node in it's own subprocess? no, I checked and did not found more python instances running, other than the mine and the Nodezator main. Why is that?

Obviously you have some sort of concurrency with all the nodes.
How do you handle the main_callables to run independently but yet pass the output an inputs. (hmmm i think i know it now) it sparked as i was writing. Nodezator kind of import the node functions and runs them from a single process/pyfile?

There is no concurrency at all presently. All execution is sequential. As I said before, I must still design a concurrency/parallelism model, and the main hurdles for that is that such design must: (1) take into account all the available paradigms to avoid problems during execution, like nodes which would otherwise run normally ending up raising errors due to various reasons like scope/race problems and (2) allow the entire graph to be exported as the exact equivalent Python code (that is, it must also execute concurrently/in parallel).

If I had implemented my own arbitrary concurrency/parallelism model without properly understanding all implications and corner cases I'd risk limiting what kind of code Nodezator could properly run.

Regarding how the nodes are loaded, each node is loaded as a separate module/package. They are completely (or mostly) independent from each other. By mostly, I mean that there is a way for nodes to share resources: by importing them. This is explained in the manual here: https://manual.nodezator.com/ch-defining-your-first-node.html#sharing-resources-among-nodes

That's why each node sits on its own folder within the categories instead of all of them being part of the same file like in other node editor projects. I designed the node packs like that, with nodes as independent from each other as possible, for 02 (two) reasons.

First, because the simpler the functions, the more easy it is to combine/compose them into powerful graphs. Using an analogy, the simpler/smaller the Lego® pieces, the more freedom of building one has. For graphs it is just like that as well. It becomes more easy to compose them into many different graphs.

Although Python is a multi-paradigm programming language (though mostly object-oriented), one of the most powerful paradigms in terms of both power and flexibility is FP (functional programming), and it works particularly synergistically with node editing (although I don't mention this specifically in the manual, many FP tools are demonstrated/taught in it, like this recipe from one of its appendices and the usage of the callable mode for both branching and looping, in their respective chapters). Why am I mentioning FP? Because just like in Lego®, FP also encourages simpler/pure functions.

I'm not talking about simplicity as the opposite of complexity here, but just in the sense that a node doesn't depend on other nodes. Its source can still be as big as needed (just like the more specialized, thematic, bigger Lego® pieces). The node source may even consist of multiple modules. As long as it doesn't depend on other nodes, it is much more easy to compose them.

The second reason I made nodes as independent as possible from each other is for the sake of the very concurrency/parallelism that we've been discussing. The less state/side effects an operation has, the easier it is to run it concurrently or in parallel.

Of course, I had only 02 years of (serious) Python experience when I started making Nodezator in 2019, so I intend to change/relax a few decisions I made back then when I didn't have enough experience nor as much insight and feedback as I have now after discussing my decisions with a lot of users and developers and testing my early ideas/decisions. Even so, the principles behind the decisions should remain, even though the form they take may change a bit.

---

I'll stop for now since I don't have much time, but I'll come back to address the rest of your comment as soon as I can (probably next week).

Have a nice weekend!

Peace.

[KennedyRichard]

About this "questions"
"Should we parse/analyse the code? Should we simply allow users to tell us via a specific variable?"
Some thoughts:
Most of Nodezator and python users in general, don't use co-routines intensively, so even when i think Nodezator might benefit from "parse/analyse" even more, this will involve probably lot of meticulous planning and might end not even feasible due to edge cases, and meta-code that will make your parser writing a nightmare. (Nested code will drive you crazy)
I guess "advanced" users such co-routiners and threaders will be well enough programmers to understand software complexity, and willingly pass a flag variable to clarify the concurrency solving specifics that should be expected.

I mentioned parsing/analysing for the sake of completeness. In practice, it is not only a nightmarish, but fraught with edge-cases and guessing and, as you aptly pointed out, likely unfeasible. It is the very reason why I use variables like "main_callable", etc. instead of reading them from the node's source. For instance, other users argued before in favor of parsing the code and automatically identifying the main callable, but I explained the impracticality of that in detail to them.

As for coroutines, it is true they are seldom mentioned in Python materials/content, and likely used even less. However, if my research at some point do indicate their usefulness over alternative approaches, I'm inclined to also allow some sort of concurrency using them, specially as I want to Nodezator to be as equivalent to Python as possible.

---

With that, I think I replied to all the main points of your previous message. Now only need to answer to this comment.

Of course, if you need to discuss anything further, don't hesitate to comment again and again. As always, I'll answer when I can.

Peace

[00-0o]

Hey Kennedy, how's it going, nice to read your comments!
Thank you for taking the time!!
I've been a bit busy with some stuff, my "game editor" is under refactoring, i tried to get rid of pygame in favor of pysdl2, i managed to migrate some code but it got too frustrating, so i'm still pygame dependent.
Until i figure out a better way i decided to just use blender 2.79 to layout my scenes, and export to a scene json file.
My little project aims to simplify point and click adventure design in a similar way AGS Editor does, but in a python based framework. Right now is just a few classes that handle mouse interaction, rendering, audio and navigation.

About your comments:

"Mostly, I need to check and understand inner workings and implications of running the app or parts of it in another thread. I'll probably end up using 80 to 90% of your original solution, though. Also, for now, I don't have a timeline for this, as it is not an urgent task nor a much requested feature. As you said, I'll leave it here for others that may need a similar solution.

However, since it is a very small change, I'll see if I can indeed include it in a patch in the future."

As you might have noticed, the launcher i made only runs a thread to prevent Nodezator to take control over the terminal in which i embed the terminal, so the Nodezator process is still independent, no risk of collision there.
Therefore as said before, being such a simple launcher and simple code, it can be implemented as Nodezator "-T" flag.
Of course if you want to use the same approach to have a console within Nodezator im pretty sure it'll be "simple" just depending on Nodezator intricacy, but you are familiar with the code base so no worries there.

I honestly think it'll be a great addition, but fully understand it's not priority, even more so having a way around it already.

"There is no concurrency at all presently. All execution is sequential."

I see, so the reason i wasn't able to interact with my other nodes from the console was perhaps: the nodes are in separate folder, or perhaps due to lack of execution, they where there but never ran. Silly XD!

I'll take a look at these links you placed there, if i have comments on that i'll let you know.
I've being looking at your game code blue..."-something", very cool stuff there, the recording feature is a very nice touch, also i saw your deque implementation, i guess to prevent in-execution modification, very clever indeed.

Then about parsing, you might had already pinpointed the caveats of such approach, so to reinforce your view on all this, i did an attempt to a parser with the help if IA thinking on how Nodezator was working under the hood, (to just avoid rewriting functions to make nodes.)
The code example is in the discord, but you'll see there, that in the end i just used typing, eval, and string split/strip, to figure out the return types. Because the combinations are endless List[List[int, float, str], tuple[etc, etc]], so it becomes more of a os.walk graph transverse situation, where a parser gets very error prone, and debugging syntactical errors is edgy.
Also:

I'm inclined to also allow some sort of concurrency using them, specially as I want to Nodezator to be as equivalent to Python as possible.

So for this there's the considerations: python does not type enforce, i dont think Nodezator should either to be "as close to python as possible", but i dont see a way around it due to the nature of the task. It is how you define the sockets without knowing the type expected, being python a dynamic type language, you'll very likely have issues anyway, therefore this should be left to user discretion.

And about concurrency, i see no problem on the current approach, Nodezator is a node based abstract system, if a given user wants to do high concurrent functional programming perhaps he should not use Nodezator to begin with, but since the door is open with "callable mode" (i haven't found a need to use it yet), but i can see loop's are something that needs have robust support. And there you have some sort of concurrency/race, edit[of course loops can already run within the node function but] that can perhaps be addressed by running the loops on separate thread, or having Nodezator specific nodes that run static loops. like they do in taichi https://www.taichi-lang.org/
The taichi approach might solve somehow the need to run separate threads because it runs much faster, but i dont know how good will it integrate with the current state of execution pipeline.

Hope this gives you some ideas for the future, im looking forward to see more Nodezator cool development!!
Have a great evening!!