Code that ought to run fast, but can't due to Python limitations.

Hendrik van Rooyen mail at microcorp.co.za
Mon Jul 6 10:04:30 EDT 2009


"Jean-Michel Pichavant" <jeanmichel at s....ns.com> wrote:

> Woot ! I'll keep this one in my mind, while I may not be that concerned 
> by speed unlike the OP, I still find this way of doing very simple and 
> so intuitive (one will successfully argue how I was not figuring this 
> out by myself if it was so intuitive).
> Anyway I wanted to participated to this thread, as soon as I saw 'due to 
> python limitations' in the title, I foretold a hell of a thread ! This 
> is just provocation ! :-)

The OP was not being provocative - he has a real problem, and the
code he is complaining about already does more or less what my
snippet showed, as I rushed in where angels fear to tread...

The bit that was not clearly shown in what I proposed, is that you
should stay in the individual states, testing for the reasons for the
state transitions, until it is time to change - so there is a while loop
in each of the individual states too.  It becomes a terribly big structure
if you have a lot of states, it duplicates a lot of tests across the different
states, and it is very awkward if the states nest.

Have a look at the one without the dict too - it is even faster as it
avoids the dict lookup.

That, however, is a bit like assembler code, as it kind of "jumps" 
from state to state, and there is no central thing to show what does,
and what does not, belong together, as there is no dict.  Not an easy
beast to fix if it's big and it's wrong.

- Hendrik






More information about the Python-list mailing list