c[:]()

[Warren Stringer]

> "Marc 'BlackJack' Rintsch" <bj_666 at gmx.net> wrote in message
> news:pan.2007.06.03.20.03.25.278011 at gmx.net...
> || Warren Stringer wanted to call the functions just for the side effects
> | without interest in the return values.  So building a list of return
> | values which is immediately thrown away is a waste of time and memory.
> 
> Also unnecessary: for f in callables: f()

What do you mean?

This is very relevant to what I need to implement now. I am converting a
domain specific language script into python statements. For debugging the
script gets parsed and generates a .py file. The final bypasses the
intermediate step; instead it parses the script and does something like
this:

    code = compile(_call,"ParseCall",'exec')
    for coname in code.co_names:
     ... cleanup goes here
    exec code in self._dict

I am already worried about speed. There are about 2000 macro statements that
look like this:
	
    demo4:    demo.stop()
              ball.smooth()
              video.live() 
              preset.video.straight()
              view.front3d() 
              luma.real() 
              seq[:]lock(1)

In this example, the preprocessor translates the statements into a list of
10 callable objects. That last `seq[:]lock(1)` statement generates 4 objects
on its own. All of the __getattr__ resolution is done in the preprocessor
step. For the sort term version are no return values. For the long term
version, there may be return statements, but prefer simplest, for now.

It sounds like list comprehension may be slower because it builds a list
that never gets used. I'm curious if eval statements are faster than def
statements? Any bytecode experts?
 
Sorry if I got sidetracked on philosophical discussion, earlier. The above
example is lifted from a working c++ version with a tweaked syntax. This is
a real problem that I need to get working in a couple weeks. 

As an aside, the code base will be open source.

Much appreciated,

\~/