Use the same format to define inputs and outputs

[GrimPixel]

Take that mynodepack as example: to define an input, it is radius:float=1.0; to define an output, it is {'name': 'circle_area', 'type': float}. Could the output defined the same as the input for simplicity?

[KennedyRichard]

I didn't have the time to think about that recently to be honest, but I'm always on the lookout for clean, clear and simple ways to simplify this kind of thing. If you (or anyone reading this) have any specific suggestions on possible formats, just post it here in this discussion and I'll take into account in the future when tending to this.

[GrimPixel]

Yes. I forgot the quotation marks.
How about this: ["circle_area", "float"] If there are only two values, they are recognised as “name” and “type” by default.

[KennedyRichard]

That's a good format, except the float doesn't need quotes, since it is not a string object, whereas circle_area needs the quotes since it is a string. My only discontentment with this is that the gains are minimal.

Here's your proposal next to the current way to do the same:

['circle_area', float]                   # scenario A (your proposal)
[{'name': 'circle_area', 'type': float}] # scenario B (current way to do the same)

You only save slightly more than a dozen characters to do the same thing. But to enable your suggestion I'll have to add a new elif clause in the code to account for it and also more lines to explain everything in the manual. That's why although your suggestion makes sense, I don't believe it justifies the effort.

Moreover, although your suggestion looks a bit "cleaner", it is also less explicit, whereas the current implementation explicitly states the purpose of each piece of data (that is, what is the name and what is the type). By using your proposal, only people aware of the syntax will understand the purpose of 'circle_area' and float when they see them, whereas by the current method, even people who don't know about Nodezator at least will have an idea that something named 'circle_area' has a type float.

Regardless of this, the main reason is that the gains are minimal. I'll give it a bit more thought, but for now I'm inclined to not implement this for the reasons I pointed out.

[GrimPixel]

I thought the output can be as close to the input as possible and in the ideal situation, the same. I see that you are busy. Maybe I can do a pull request myself later? It can be seen as an Easter egg.

[KennedyRichard]

Of course you can submit a pull request. Anyone can submit a pull request anytime. The Indie Python project is not a project where people need permission to do things. Just use your common sense and do things assuming that people will be supportive or at least understanding.

At best, your PR will be accepted and at worst it will be politely rejected with a proper explanation as to why (so at least it will be a learning experience). PRs take between a few weeks to a few months to be reviewed due to my tight schedule, but I eventually review everything. More likely though, even when the PR is okay, I ask people to make further changes to improve the quality, or make them myself when the changes are small enough.

In this specific case though, since I already expressed my assessment that this change isn't worth the work and additions, submitting a PR would be unproductive.

Again, as an open source maintainer, it would be unreasonable and rude to just blatantly reject peoples ideas/suggestions which is why I strive to always give proper reasoning/clear arguments to justify my decisions. I think I was already clear enough in my last response, but I'll try justifying my opinion in the matter even more.

Please, take a look at this issue in the pygame-ce repository in which I gave my opinion: pygame-community/pygame-ce#2414

The issue was closed and the related PRs were rejected for the same reasons that I'm not willing to implement this suggestion. Even though the suggestion in that issue and related PRs is not bad per se, it just introduces more code in the repository for too little gain.

That is not the only reason though. In an open-source project, no one is more important than others, so every decision must consider people equally and be made based on objective arguments, not subjective reasons. If that small change in pygame-ce was accepted, it would make it even more difficult to justify denying other tiny changes in the future. Why allow it for a person and deny it to another person? That's why maintainers must not make exceptions.

There is yet another reason: no matter how tiny the change, all added code contributes to increasing the volume of the application and thus increases the time and effort required for maintaining the app. Developing an app is not just about adding missing features. Over time, with each added feature, the complexity of the package increases. This requires maintainers to schedule time and work to reduce the complexity by refactoring. That is why, as much as I'd like for people to have all their suggestions added to Nodezator, in practice, I know that it just isn't feasible and would inevitably lead to making the app unmaintainable.

Here's another reason: although you'd like for outputs to be more like inputs, they can never be equal to each other anyway. Just cause they are in opposing sides of a function, doesn't mean there is symmetry between them. Functions allow multiple inputs but don't allow multiple outputs (we fake multiple outputs by returning a dictionary, but in fact, the function only returns a single object, which is the dictionary).

And yet, I do understand your restlessness regarding the asymmetry between how the input and output are defined, I truly do. My point though, is that I cannot justify such change with purely objective arguments which is why I cannot accept it. As the maintainer, I strive to protect the app's future, and I believe the best way to keep it that way is by keeping it as simple as possible.

Everyone in the project must present good reasons for proposed/submitted changes. Even myself, the maintainer, am not exempt from that. For instance, I submitted a proposal for a feature in Nodezator last year and ended up rejecting/giving up on it after discussing it for several months with the community, as can be read in this excerpt:

after a prolific discussion between me and Mr. Alexander, at our own pace over 02 months, including research and the presentation of strong and coherent arguments against my proposal, I rejected my proposal...

The excerpt above is in the top post of this discussion: #34

Again, if you still disagree with me, we can discuss things further if you wish, but I believe I've already presented more than enough reasons not to pursue this suggestion.

Peace

[GrimPixel]

It is well explained. I agree with you: when it is complex enough, any further complexity is to be assessed.
This means two solutions: keep declaring the output that way; omit declaring the output and avoid the type check mentioned in #47.
The second solution is related to the approach of aggregating all forms of a formula mentioned in #62, as the output can vary in type. A possible rule of that approach is to use aggregated form only when types are the same, so the output is still declared.
It looks like I'll stick the original one: declare types of the output in a dictionary.

[KennedyRichard]

I myself, as I said, don't have much to contribute to this discussion at the moment, since I didn't schedule any time to ponder about this. But something that I have been contemplating from time to time is to allow usage of a typing.TypedDict to define multiple outputs.

However, this has some limitations considering future features I want to implement for node outputs, like the ability to "mute" nodes, so even if I accept this I'd not include it right now, but it is definitely something to consider in the future.