On May 6, 12:28 am, [EMAIL PROTECTED] wrote: > > 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?
Datafiles could be implemented with SQL. Consider SQL: SELECT * FROM process_dict where id = 1 . SELECT * FROM process_dict where id = 1 Obviously, this is all a supposition, I'm not claiming the code is perfect (or am I ?). If datafiles could be implemented with SQL and storing text requires datafiles, then I can store text with datafiles (haha !). Would you consider doing this ? One could even store python decorated serialized code using SQL [supposition]. But would it be useful [haha !] ? I don't know. -- http://mail.python.org/mailman/listinfo/python-list
