[Python-Dev] switch-based programming in Python

[M.-A. Lemburg]

"Martin v. Loewis" wrote:
> 
> > > 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.
> 
> You would need to generate the byte code literally. Come up with a
> byte code definition for this feature, support it in ceval, then come
> up with a byte string that is an example for a large optimized "if"
> chain, and generate a code object from it. Adapting Lib/compiler may
> be helpful in generating byte code more flexible.
> 
> Only when it is known that this byte code that you generated more or
> less manually indeed performs significantly faster, only then it would
> be worthwhile looking into parser/compiler support for that byte code.

Ok.
 
> > 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 ;-).
> 
> If it is unacceptably inefficient, perhaps this approach to XML
> parsers is doomed to fail...

It is not unacceptably inefficient. Indeed this approach
already outperforms the method callback based one using the
current Python versions and long if-elif-else statements. 

What I'm argueing for is that we make it perform even better ;-)
 
> > 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.
> 
> I think people have successfully used dictionaries of functions for
> that. Why do you insist on generating long "if" chains?

I don't "insist" on any programming technique. It just happens
that I have made very good experience with this kind of
approach in both C and Python (except that Python could be made
smarter when it comes to finding the right code snippet to
execute).
 
> > Now how could the compiler be provided with the needed
> > information... ?
> 
> I still think this is the last question to ask. First define the
> opcodes, and show us that they really do speed up things, then look
> into the syntax needed to support this optimization.

I'll do that, but only if people on python-dev agree that it's
worth trying (I'm +1 on it, obviously). There's not much point
investing time into something which then get's lots of -1's
just because I can't convince you guys of the benefits, 
whether its performance, gaining new grounds for Python 
development (writing low-level fast parsers in Python) or simply 
introducing a different way of approaching a common problem
(method callbacks vs. switches).

> If you think you need an annotation, you may just as well propose to
> introduce a switch statement into the language.

True, but that would probably be even harder to get accepted 
on python-dev (or would it ;-) ?
 
>   switch x:
>     case 'foo':
>       ...
>     case 'bar':
>       ...
>     case 42:
>       ...

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