Code that ought to run fast, but can't due to Python limitations.
Hendrik van Rooyen
mail at microcorp.co.za
Sun Jul 5 15:45:45 CEST 2009
"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
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...
More information about the Python-list