To input node name only once

[GrimPixel]

Take “mynodepack” as an example, “circle_area” appeared trice: folder name, function name, variable value. It could be great if it only requires to be written once.

[GrimPixel]

I have a solution:

All main-callable functions are named the same, as callable() or simply _()

together with the approach mentioned at #62, to name files and disuse the folder:

nodepack
└─ formulas (category)
   ├─ circle_area_from_radius.py
   ├─ circle_area_from_diameter.py
   └─ circle_area_from_circumference.py

[KennedyRichard]

I understand your point and the repetition is indeed annoying. However, there are trade-offs if we were to do it differently. I'll explain/demonstrate.

It is an unwritten principle in Nodezator to avoid "polluting" user code as much as possible.

The demonstration: imagine a Python developer completely oblivious to node-based programming sees the following code anywhere on the internet or real life:

from math import pi

def circle_area_from_radius(radius):
    return pi * radius**2

main_callable = circle_area_from_radius

Do you think that developer could tell this code is associated with any framework/app/API?

No, right? That developer probably wouldn't even suspect it. Except for the main_callable assignment, that code is as pure as it can be.

This is the kind of code anyone will find whenever inspecting the source of an user-defined node in Nodezator and I think this is the right and best way to do things. If you bend your code too much to satisfy the unjustified needs of an API/app/framework, your code will become harder to read at best and bloated beyond recognition at worst.

That's the trade-off: by tolerating a bit of repetition, your code remains as simple, readable and reusable as possible. This is why I don't intend to change how this works in Nodezator, despite sympathizing with your annoyance at the repetition. It is also one of the main reasons I created Nodezator despite other equally awesome node editors being available.

Pick any existing Python node editor other than Nodezator and try to define a node using the code above. You'll be surprised how much stuff will be added to that code. At the very least you'll probably have to import and subclass something. I don't mean to disrespect other apps, their developers might have had their reasons to make such decisions. However, I wanted something simpler, something to which I could tell: "hey, would you please take this function and give me a node?"

I hope you understand my reasoning, but I'll always encourage and respect different opinions. As always, if you have more to add, I'm here to listen and discuss things further. Thank you for always sharing your ideas/concerns/feedback on Nodezator.

[GrimPixel]

Thanks for the explanation. It s about the universality.
How about removing that “main_callable”? As there is only one function left in a file, only it can be the callable. Any other functions needed are placed inside it, then.

[KennedyRichard]

That is clever, but surprisingly impractical. People have suggested it in the past. The problem is that we would have to parse the code to determine what is the main callable. However, parsing code is too error-prone and filled with edge cases.

Asking the user to point to the main callable by just aliasing it as main_callable is straightforward, easy for the user and much less error-prone. In Nodezator and the Indie Python project in general we avoid code parsing as much as possible.

Here's just one edge case: the namespace of a node script already contains many callables that can be turned into nodes from the get-go. For instance, this is a valid node script:

main_callable = pow

Without the main_callable, we would not be able to determine which callable the user wants to use, since there are other callables available in the namespace as well, like list, tuple, isinstance, etc.

It is true that all these callables are already available within Nodezator as built-in nodes, so we could in theory exclude them from our parsing. Even so, in the unlikely event that the Python language introduced a new built-in, the user wouldn't be able to use it until we added it as a default node already, since the user wouldn't be able to use a main_callable variable to point to it.

But okay, let's assume this won't happen, so we just have to worry about parsing code provided by the user.

Well, even so, this is harder than people realize and is probably a problem for an entire Python package altogether, not something to be casually added to an existing package. The number of edge cases is just too large, such software would need constant revisions and would have to be constantly amended for new use-cases. For instance, a node can be any callable. It can be a class, but it can also be one of its methods. float can be a node. float.__add__ can also be a node, and so on.

Look at this other valid node script which defines a node that returns a number multiplied by 3.0:

main_callable = __mul__ = 3..__mul__

In any case, even if it would be possible to write such parser, don't you agree that asking the user to just point out the callable to use saves us a lot of time and energy that we can otherwise use in other more urgent and important features?

Even so, thank you for pointing that out. Asking and suggesting things, no matter the end result or whether someone already suggested something creates opportunities like this one to discuss things further and learn. So never hesitate to ask/suggest stuff.

Peace

[GrimPixel]

Thank you for the detailed explanation. The parsing is to be avoided. Now I have a deeper understanding of the purpose behind it.