[03:43:00] I presume if a Python function implementation imports something from the standard library, and that function is run some number of times, that the thing will be imported that number of times? [03:49:49] (alternate question: if a number of functions' implementations depend on, say, the function "field" from Python's dataclass module, is it more efficient to add the import to each of the implementations individually, or to expose the module via another function that just does "return dataclass.field(Z...K1)" and use that?) [08:15:59]

" I presume if a Python..." <- I don't think so , python ensure that iirc? [18:40:06] Sure, but is this true with respect to the Notwikilambda orchestrator? [19:13:35] Currently, the evaluators are always called independently, for every subcall. We plan to improve that at some point and this should reduce resource requirements. But for now, every import will be evaluated as often as the implementation is being called. [19:22:43] but also, I expect returning a dataclass.field value from a function and using it in another function won’t work properly? [19:22:54] since it’s probably serialized in some way [19:26:58] Not sure why I used dataclass as the function in my example initially; how about, say, math.sin? (re @lucaswerkmeister: but also, I expect returning a dataclass.field value from a function and using it in another function won’t work properly?) [19:27:49] hm, I see [19:27:53] (e.g. using a ZObject for taking the sine of a given argument vs. having "from math import sin" in each function implementation requiring the sine of something) [19:28:24] if you have a sine function, then the function orchestrator can cache its results IIUC [19:28:43] but it would have to be a pretty expensive function for that to matter [19:28:58] otherwise I’d expect importing math.sin to be much faster [19:29:58] So then my question would have been "what if the function were expensive?" [19:30:09] which I think has been answered (re @vrandecic: Currently, the evaluators are always called independently, for every subcall. We plan to improve that at some point and this should reduce resource requirements. But for now, every import will be evaluated as often as the implementation is being called.) [20:00:41] Yeah, in order to hand a dataclass.field across function boundaries, we would need a type and appropriate serialization and deserialization to work. It doesn't yet. [20:03:11] We certainly have ideas to make the orchestrator and evaluator smart enough to not require the contributor to have to worry about these things. But we're far away from that and likely won't be there by launch. [20:04:46] what are the currently supported types to pass around? strings and numbers? or also JSON arrays/objects (Python lists/dicts)? [22:04:02] I think it's only strings right now [22:04:11] That should change by the end of the phase [22:04:21] Oh, and boolean [22:16:54] ah, okay [22:17:19] I guess numbers already gets you into trouble because Python has those infinitely large integers and JS barely has integers at all ^^ [22:54:46] Numbers spell trouble