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

[Hendrik van Rooyen]

"Steven D'Aprano" <steve at REMOVE-THIS-cy..e.com.au> wrote:

>On Sun, 05 Jul 2009 10:12:54 +0200, Hendrik van Rooyen wrote:
>
>> Python is not C.
>
>John Nagle is an old hand at Python. He's perfectly aware of this, and 
>I'm sure he's not trying to program C in Python.
>
>I'm not entirely sure *what* he is doing, and hopefully he'll speak up 
>and say, but whatever the problem is it's not going to be as simple as 
>that.

I am well aware that John is not a newbie.
He was complaining about Python's lack of a case statement
in the context of a state machine.

The point I was trying to make is that, if any state machine
is examined, then, if you examine any one state, the reasons
for leaving it ("state transitions") is always a subset of the
choices that _can_ be made.

So that drawing a circle round each state in a state diagram, 
and making a routine to examine the arrows leaving that circle,
and returning the destination point of the chosen arrow,
is a way of splitting the job up, and results in making only 
the relevant decisions at the time of their relevance.

This is in contrast to the classic C way of making one big
case statement to implement a finite state machine, which
gets its efficiency (if any) out of compiler optimisations
such as replacing a skip chain with a jump table.

I understand that it leads to a lot of what looks like 
boilerplate code, but he was looking for speed...

- Hendrik