[Python-Dev] switch-based programming in Python

[M.-A. Lemburg]

"Martin v. Loewis" wrote:
> 
> > > That won't work. You cannot know what type "x" has, so you don't know
> > > in advance how "x == 'one'" is evaluated.
> >
> > But you do know that x won't change from one compare to the next,
> > so a single dictionary lookup could replace the equality tests
> > (provided that x is hashable).
> 
> How do you know x won't change? I certainly can write a class where it
> does.

You mean one where calling the compare slot causes the object
value to change ? Ok, you can always construct a case where this
fails due to the dynamic nature of Python -- that's why the compiler
will probably need some extra information to do the right thing 
here.
 
> The key issue is that x must be hashable. If it is (including the
> constraint that a==b implies hash(a)==hash(b)), then I agree that this
> transformation would work.

Dito.
 
> > What do you think about the general idea, BTW ?
> 
> I'm also uncertain that this would give any speed-up. I assume you
> want to generate a dictionary {rhs-string : byte-code-address} or the
> like. I'm not convinced that the dictionary lookup + computed goto is
> necessarily faster than the compare sequence; 

It would be for large if...elif...elif...else switches which 
is what I'm after here. These constructs are currently not used
so much in Python because of them being rather slow (O(n) on
average rather than O(1) for perfect hash tables).

> this could be
> established only by implementing it (you don't need to implement
> the parser/compiler aspects, just the changes to ceval.c).

Hmm. How is that supposed to work ? I would like the compiler
to generate different code for these "switch" statements. It
would also have to generate the hash table and store it in
the constants.
 
> There are also some security aspects here: I assume you'll put the
> dictionary into the constant pool (co_consts). Of course, a dictionary
> is not const, so somebody may change the dictionary, thus letting you
> jump to code positions which were not intended as jump targets.

We'd need a perfect hash table object for this which would have
to be read-only by nature.
 
> Finally, I guess tools analysing byte code will be confused.

True, since we'd probably need some new opcodes for this.
 
> So I'm -1 on it until I see that it actually does any good. Then I'm
> -0 until I see that it does that good in real-life applications (of
> course, your application would be one, but I'd like to see a second
> one :-)

Well, just try to write an XML parser using mxTextTools and the
taggin engine which then generates a tag list to be processed in
Python by an if..elif...else "switch" statement and
compare the speed to a method call based one. You'll note the
difference in performance (and have a second application ;-).

This is just one aspect, though. I think that a lot more state
machine like code could be written in Python if well-performing
"switches" would be possible in Python. That would keep the
requirement to write C code for fast execution small and reduce
the need for callbacks a lot. The net result for these application
would be a significant win in performance and flexibility.

Now how could the compiler be provided with the needed 
information... ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/