To provide some feedback I vould like to show the code which works fine
for me as a FSM machine. As speed is not the crucial issue for my
application, I have decided to use an approach showed in the Skip
Montanaro's code.
http://orca.mojam.com/~skip/python/fsm.py
(it is using dictionary to store
On Wed, 25 Jan 2006 15:50:27 -0600, [EMAIL PROTECTED] wrote:
If they need to resume their calculations from where they left off
after the last yield.
Wolfgang Well, no, independently from that.
Wolfgang Just to avoid to inital overhead of the function call.
How do you pass
On Tue, 24 Jan 2006 14:58:27 -0600, [EMAIL PROTECTED] wrote:
Wolfgang So basically if I want to write a long-running program in
Wolfgang Python, it would make sense to code all functions that are
Wolfgang likely to be called more than once as generators...
If they need to resume
So basically if I want to write a long-running program in
Python, it would make sense to code all functions that are
likely to be called more than once as generators...
This was meant as a question.
If they need to resume their calculations from where they left off after the
last yield.
Wolfgang Keller wrote:
So basically if I want to write a long-running program in
Python, it would make sense to code all functions that are
likely to be called more than once as generators...
This was meant as a question.
If they need to resume their calculations from where they
what makes you think that resuming a generator won't involve function
calls ?
That was not what I wrote.
I referred to what Peter Hansen [EMAIL PROTECTED] wrote in
[EMAIL PROTECTED]:
I believe the more modern approach to this is to use generators in some
way, yield each other as the next
Wolfgang Keller wrote:
The way I understand this, resuming a generator causes less overhead than the
inital overhead of a function call.
I don't have Python 2.4 handy, but it doesn't seem to be true in 2.3.
I'm not very proficient with generators though, so maybe I'm doing
something stupid
Wolfgang Keller wrote:
what makes you think that resuming a generator won't involve function
calls ?
That was not what I wrote.
I referred to what Peter Hansen [EMAIL PROTECTED] wrote in
[EMAIL PROTECTED]:
I believe the more modern approach to this is to use generators in some
way,
Wolfgang So basically if I want to write a long-running program in
Wolfgang Python, it would make sense to code all functions that are
Wolfgang likely to be called more than once as generators...
Skip If they need to resume their calculations from where they left off
Skip
If they need to resume their calculations from where they left off
after the last yield.
Wolfgang Well, no, independently from that.
Wolfgang Just to avoid to inital overhead of the function call.
How do you pass in parameters? Consider:
def square(x):
return
On Fri, 20 Jan 2006 05:16:57 +0100, Peter Hansen wrote
(in article [EMAIL PROTECTED]):
I believe the more modern approach to this is to use generators in some
way, yield each other as the next state. This way you avoid all almost
all the function call overhead (the part that takes
Wolfgang Keller wrote:
On Fri, 20 Jan 2006 05:16:57 +0100, Peter Hansen wrote
(in article [EMAIL PROTECTED]):
I believe the more modern approach to this is to use generators in some
way, yield each other as the next state. This way you avoid all almost
all the function call overhead (the
Wolfgang So basically if I want to write a long-running program in
Wolfgang Python, it would make sense to code all functions that are
Wolfgang likely to be called more than once as generators...
If they need to resume their calculations from where they left off after the
last yield.
On Tue, 24 Jan 2006 21:19:26 +0100, Carl Cerecke wrote
(in article [EMAIL PROTECTED]):
def g_on():
print on
action = next_action()
if action == 'lift':
yield g_on()
elif action == 'push':
yield g_off()
else:
yield None
def g_off():
Carl Cerecke wrote:
It turns out that generators are more efficient than the eval function
excuting bits of compiled code. About 20-25% faster.
why are you using generators to return things from a function, when
you can just return the things ?
def f_on():
print on
action
On Mon, 23 Jan 2006 08:53:59 +1300, Carl Cerecke [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
On Thu, 19 Jan 2006 23:16:57 -0500, Peter Hansen [EMAIL PROTECTED] wrote:
How about something like
actions = dict(
...a=compile('print A; state=b','','exec'),
...b=compile('print B;
Bengt Richter wrote:
On Thu, 19 Jan 2006 23:16:57 -0500, Peter Hansen [EMAIL PROTECTED] wrote:
How about something like
actions = dict(
...a=compile('print A; state=b','','exec'),
...b=compile('print B; state=c','','exec'),
...c=compile('print C; state=None','','exec')
Sorry, I can't get in. Can you please show me, how to use your approach
on the simple push/push ON/OFF button for example please?
PS: seriously it is not a homework :) and I feel it like a shame I am
asking such a simple questions :(
States: ON, OFF
Transition event: push, lift
transition
Sorry for the typo in my previous posting. Of course it has to be:
simple liftt/push ON/OFF button
--
http://mail.python.org/mailman/listinfo/python-list
Petr Jakes wrote:
Sorry, I can't get in. Can you please show me, how to use your approach
on the simple push/push ON/OFF button for example please?
PS: seriously it is not a homework :) and I feel it like a shame I am
asking such a simple questions :(
States: ON, OFF
Transition event:
On Thu, 19 Jan 2006 23:16:57 -0500, Peter Hansen [EMAIL PROTECTED] wrote:
Carl Cerecke wrote:
Carl Cerecke wrote:
Ah. Well, my post suggested, as one option, the callables call
each other directly.
Doh! No I didn't. And they shouldn't. Otherwise the call stack
gets out of hand. But I did
On Fri, 20 Jan 2006 10:27:58 +1300, Carl Cerecke wrote:
We want a goto.
Unfortunately, this is about the only problem I can think of where gotos
are useful. And for reasons well explained elsewhere, gotos are Not Good.
I've solved this in a very efficient, but rather unpythonic way.
Hello,
I am trying to study/understand OOP principles using Python. I have
found following code http://tinyurl.com/a4zkn about FSM (finite state
machine) on this list, which looks quite useful for my purposes. As
this code was posted long time ago (November 1998) I would like to ask
if the
Petr Jakes wrote:
Hello,
I am trying to study/understand OOP principles using Python. I have
found following code http://tinyurl.com/a4zkn about FSM (finite state
machine) on this list, which looks quite useful for my purposes. As
this code was posted long time ago (November 1998) I would
Petr Jakes wrote:
Hello,
I am trying to study/understand OOP principles using Python. I have
found following code http://tinyurl.com/a4zkn about FSM (finite state
machine) on this list, which looks quite useful for my purposes. As
this code was posted long time ago (November 1998) I would
On Fri, 20 Jan 2006 10:27:58 +1300,
Carl Cerecke [EMAIL PROTECTED] wrote:
Petr Jakes wrote:
[ a query regarding some 1998 python code that implements a finite state
machine ]
Python has no goto.
Thank goodness!
func = f_state_1 # start_state
while func != None:
func()
We've
On Fri, 20 Jan 2006 10:27:58 +1300 in comp.lang.python, Carl Cerecke
[EMAIL PROTECTED] wrote:
[...]
Python has no goto.
+1
[...]
We want a goto.
-1
Regards,
-=Dave
--
Change is inevitable, progress is not.
--
Dave Hansen wrote:
On Fri, 20 Jan 2006 10:27:58 +1300 in comp.lang.python, Carl Cerecke
[EMAIL PROTECTED] wrote:
[...]
Python has no goto.
+1
[...]
We want a goto.
-1
I agree entirely. My (rather unclearly made) point was that, for the
particular application (FSM), an
Dan Sommers wrote:
On Fri, 20 Jan 2006 10:27:58 +1300,
Carl Cerecke [EMAIL PROTECTED] wrote:
... now you have a function-call overhead on each state transition ...
Have you profiled your code and demonstrated that this particular
function call consumes too much time?
Yes. For a parser
Thanks for your comments,
The mentioned 8 years old code actually works somehow.
I am trying to solve very similar problem about FSM as the code in the
example does and I do not want to be overburden by the if/elif stuff or
by declaring state functions (which IMHO is very similar approach as
On 19 Jan 2006 15:53:54 -0800, Petr Jakes [EMAIL PROTECTED] wrote:
Thanks for your comments,
The mentioned 8 years old code actually works somehow.
I am trying to solve very similar problem about FSM as the code in the
example does and I do not want to be overburden by the if/elif stuff or
Chris Mellon wrote:
I'm not sure why nobody else in this thread said it, but the most
common way of implementing state machines I've seen in Python (unless
theres only a couple states you can manage with if/elif) is to use a
dict to map states to callables.
Ah. Well, my post suggested, as
Carl Cerecke wrote:
Chris Mellon wrote:
I'm not sure why nobody else in this thread said it, but the most
common way of implementing state machines I've seen in Python (unless
theres only a couple states you can manage with if/elif) is to use a
dict to map states to callables.
Ah.
Carl Cerecke wrote:
Carl Cerecke wrote:
Ah. Well, my post suggested, as one option, the callables call
each other directly.
Doh! No I didn't. And they shouldn't. Otherwise the call stack
gets out of hand. But I did suggest that each callable representing a
state set a global variable, just
Petr Hello, I am trying to study/understand OOP principles using
Petr Python. I have found following code http://tinyurl.com/a4zkn about
Petr FSM (finite state machine) on this list, which looks quite useful
Petr for my purposes. As this code was posted long time ago (November
35 matches
Mail list logo
