[Python-Dev] switch-based programming in Python (original) (raw)

M.-A. Lemburg mal@lemburg.com
Thu, 08 Nov 2001 11:55:10 +0100

"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 (coconsts). 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/