Gh Python component - why the code input?

It made sense when that was the only way, but why should there be a code input for the gh python component if you can just double-click and edit the code like any other scripting component? Is the hope that you could construct python code dynamically using string tools?

Not that it's so bad, but I never use that string input. On second thought, what about a file path input for inputting modules, instead of code as a string? That would be a nice option. Or a folder path(s) input for adding libraries to sys.path ... Ok I'm starting to dream now.

Replies to This Discussion

Permalink Reply by Benjamin Golder on July 13, 2011 at 4:41pm

actually, here:

Attachments:

module and path.ghx, 38 KB

Permalink Reply by Giulio Piacentino on July 14, 2011 at 8:42am

Hi Benjamin,

About code input

I'd say it's there because it's an input and Python is suited to accept it, while other "scripting" components cannot, with the exception of F1, F2..., that are evaluated by Grasshopper and therefore can use it.

The idea behind code input is really just the fact that Python is evaluated and is able to accept it. This could be also achieved on user's side by using exec or eval, something that in this form does not even exist in C# and Vb.Net. Maybe often today you do not need that feature, but it might be useful in some cases. Evaluating arbitrary text is something that is quite cumbersome to do in Vb.Net and C# "scripts". Because of how the runtime works, compiled methods are not garbage collected and they can fill available memory relatively quickly, unless you take extreme measures against it.

Note that, because of this, in theory it is possible to use up Rhino's memory with Vb.Net and C# components through shear multiple compilation (many code changes and OKs). This is theoretical, it does probably take a fairly large amount of compiling to do so.

However, I think that there's a presentation need sometimes (to transform a Python component into a specific solver to a problem, much like with User Objects). In this case, code input is not needed, because it becomes invariant. Because of this, code input could be hidden by default, with an option to show it. I'll see if that's possible without breaking compatibility. Would this be enough to suit your needs?

https://github.com/mcneel/ghpython/issues/15

About input modules

That's a reasonable wish. It could be just a list of reference paths as in the other scripting components, or a dynamic input such as the one in the picture above. Which one do you think would make more sense?

I am just thinking that you could expose this with the simple method you showed (you should however check that the path is not already there). I've added this in any case to the wishlist: https://github.com/mcneel/ghpython/issues/16

- Giulio

_____________

giulio@mcneel.com
McNeel Europe

Permalink Reply by Giulio Piacentino on July 14, 2011 at 8:49am

File

Attachments:

moduleandpath.ghx, 28 KB

Permalink Reply by Giulio Piacentino on July 14, 2011 at 9:02am

If an option hides the code input, do you think it would make sense to also hide the 'out' output?

- Giulio

_____________

giulio@mcneel.com
McNeel Europe

Permalink Reply by Benjamin Golder on July 14, 2011 at 4:11pm

Not unless there is some other easily accessible and equivalent way to output print statements and error messages. The other scripting components all have 'out', so it would seem natural for it to be included.

Thanks!

Permalink Reply by Benjamin Golder on July 14, 2011 at 4:09pm

Thanks Giulio!

code input could be hidden by default, with an option to show it. I'll see if that's possible without breaking compatibility. Would this be enough to suit your needs?

That would be perfect, that's exactly the kind of solution I was hoping for. I am finding it far easier to develop plugins as python scripts than as gha components, but want to present something that feels a little more like a finished tool.

It could be just a list of reference paths as in the other scripting components, or a dynamic input such as the one in the picture above. Which one do you think would make more sense?

I can't imagine there would be much use to configuring paths dynamically. If someone needed to, it would be pretty easy to write the code themselves (and they already have an example here). I think having some sort of interface that could easily add to sys.path utilizing a basic file browser would aid the transition of new users and new programmers who want to interact with different code libraries, but who do not yet understand the principles of namespaces and package/module importing. It would also save time when testing and debugging scripts that use multiple packages.

RSS