Custom Code Block

holger krekel pyth at devel.trillke.net
Tue Jan 21 08:35:00 EST 2003


Hi Amir,

Amir Hadar wrote:
> I'm a colleague of Mr. Zeev. We have patched Python 2.2 with holger
> patch and it worked real nice. This can really make things easier for
> us.

i'll make a proper release of IEXEC [1] when i get some time. 
my cvs version is already cleaner and better than the one you 
are using.  But i am too busy to release it right now.

> However we still have a problem implementing a certain feature that we
> need.
> What we need is a fork bock
> Example:
> def func():
> 	<fork>
> 		print "hello"
> 	print "func end"
> 
> In this method we want the command print "hello" to run in a different
> thread.

I thought of problems like this before. With

    <fork>
        expression

your fork object is actually able to __catch__ the resulting
object of the expression.  Every object that "drops to the floor"
i.e. is not assigned to some name will get 'thrown' 
to the 'fork' execution handler. 

You can program the 'fork' execution handler to serialize
the catched object to some other process or machine
and execute there.  This has nothing to do with bytecodestrings
or code objects but takes place on the 'object level'. 

> A more generic solution will be something like a complex
> macro. Means that this method will be translated to this:
> def func():
> 	def uniquename():
> 		print "hello"
> 	fork(uniquename)
> 	print "func end"
> 
> If we could do the same without using a unique name it will be better.
> I can do this without inventing new bytecodes by simply manipulating
> the parse tree in the com_node(c,n) function. The problem is that the
> node functions/macros lake the ability to extract a child node and
> more important to get to the parent node. Without getting to the
> parent node I can't replace the block statement with another one (I
> can modify the current node instead).

You could use the python compiler-package (which my patch doesn't) 
to hack some bytecode replacement stuff into it.  But i don't think, 
that "parse preprocessing" or "compile modifications" is a 
solid easy way to get your desired behaviour. 

Especially for stuff like remote processing you want to customize
your "execution handler" to control dispatching and error conditions.
So it is better if the 'object flow' goes through the handler 
and is not a statical 'syntax replacement' at parsing time. 
Doing macros at the syntax level is widely disregarded in 
the python community.  For good reasons. 

The IEXEC protocol aims to support a clean minimal set of 
hooks so your can implement 'execution handling' at the 
user level.  

For example, I currently also use it for XML generation: 
tags are execution handlers and can react to error conditions
in their sub-structure.  They can choose to replace their 
substructure with an error description without harming the
generation of the other parts of the document.  This allows
to e.g. generate html pages that display 90% correctly and
you still see the basic stuff and don't get complicated 
tracebacks with no idea what they mean. 

> So I have the following questions:
> -Where can I find documentation on the python bytecode, running model,
> etc.?

in newsgroups or in the source code. 

> -Is there something like a VM Spec to reference.

not that i know off.

> -If I want to manipulate the parse tree, can I hook to the parser
> before the pars tree hits the compiler?

look at the compiler package and see how e.g. 'quixote' 
does it. 

> -If I modify the parse tree, can it harm in some way the compiler
> (assuming that I leave a legal parse tree after I modify it)?

If you find a good way to hook in, then this should be ok. 

> -Is there a way to hook to the parser through python code? Means that
> python will use python to compile its files in import statment.

look at the compiler package. You'll find documentation on 

    http://www.python.org/dev/doc/maint22/lib/compiler.html

have fun,

    holger


[1] IEXEC is an experimental new protocol at VM-level and
    there is some (a bit outdated) info on

        http://codespeak.net/moin/moin.cgi/IndentedExecution






More information about the Python-list mailing list