generator functions in another language

castironpi at gmail.com castironpi at gmail.com
Mon May 5 23:28:29 EDT 2008


On May 5, 1:55 pm, "metaw... at gmail.com" <metaw... at gmail.com> wrote:
> On May 4, 1:11 pm, castiro... at gmail.com 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?



More information about the Python-list mailing list