On May 5, 1:55 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > On May 4, 1:11 pm, [EMAIL PROTECTED] wrote: > > > There is no such thing as a 'frame' per se in C; byte code is > > integral. As there is no such thing as suspended state without > > frames, and no such thing as generators without suspended state. > > Well, for implementing generators there are alternatives to using > frames + byte code. In CLPython generators are implemented with > closures. (Which does not help much when it comes to reimplementing > generators in C, alas.) > > - Willem
There's a process decorator to functions in a module. [supposes] @process def datafile( processdict ): processdict.modify( ) op= yield op.call( ) in processdict # op.call( ) in namespace More simply: @process def datafile( processdict ): processdict.modify( ) interaction_object= yield invoke( interaction_object, processdict ) #or interaction_object.invoke( **processdict ) processdict.commit( ) Making each execution of process a self-modifying disk file. Interaction_object could be binary or text. If text, we'd have a cross-language executable, but I'm suspicious it wouldn't be vacuous as a Python of Python composition: would other languages pass other than Python programs? I think relational databases are the only in there. In other words, I think Python would make a wholly better stored procedure and query language than those of databases. Certainly I'm suspicious that's naivete speaking up; I question, would it? Is there more risk of or opportunity for malicious execution? Simply put, can we get primitives in to databases? What's an example of a [optionally real] operation on the primitives that doesn't map pretty well into SQL? How do you want to write base-case scenarios if they're going to be literals? -- http://mail.python.org/mailman/listinfo/python-list
