Closed Vayel closed 3 years ago
I have to think about this. My design so far has been to maintain parity with RNetLogo as much as possible. I can see the value of a simple high level interface for simple cases.
Actually, this is quite similar to BaseNetLogoModel
.
The issue with any high level API is that it can be too limited, or have weird unexpected corner cases, or requires detailed explanations of the limitations.
For example BaseNetLogoModel requires that you can specify the entire go routine from within python. Any loading of files etc. should be handled outside the go routine. Also, it relies on using text files to send results from netlogo to python. This creates IO overhead which can be slow.
I am happy to consider including something like BaseNetLogo model within pynetlogo, but it would require some careful design to cope with these various issues.
It would be useful to have an API dealing with inputs and outputs rather than with raw commands. Something like this:
Which would be used like this: