Erik Max Francis wrote:
> Terry Hancock wrote:
>
>> I doubt that helps much: I pronounce all of those words
>> (when I use them, which is not too often) as "-toopel". The
>> only tuple I pronounce with the "-uh-" is "couple", and I
>> usually call that a "two-tuple" when dealing with Python.
>
>
Dave wrote:
> This should be simple, but I can't get it:
>
> How do you loop backwards through a list?
>
> For example, in, say, Javascript:
>
> for (var i = list.length - 1; i >=0; i--) {
> do_stuff()
> }
>
> I mean, I could reverse the list, but I don't want to. I want it to
> stay exact
Eric McGraw wrote:
>>Well, it turns out to be the best way to invert a string, IMO. The
>>reversed() feature returns a reversed object... not a reversed string.
>>In short, I have to fool with it again _after_ it has been inverted. The
>>slicing takes care of the job right away and gives me what I
mwt wrote:
> I want to do programmatic terminal commands on unix with python - i.e.
> I want my program to issue commands to start and stop scripts, other
> programs, etc. I'm sure this must be fairly straightforward, but
> haven't been able to find a reference for it. Any help?
>
Try:
pexpect.s
anthonyberet wrote:
> Hello again - rather a newbie here...
>
> I want to work on a sudoku brute-forcer, just for fun.
I know what you mean. I wrote one just for fun too.
> I am considering different strategies, but first I need to decide on the
> data-structure to use for the progress/solution
Paul Rubin wrote:
> Carl Cerecke <[EMAIL PROTECTED]> writes:
>
>>3. Not as fast as byte code hacks, or using pyrex/psyco. Peter Hansen
>>is right. One of those is likely a better solution if you don't need
>>pure python.
>
>
> If you don'
Well, it doesn't quite rule them all, but it is fast: About three times
faster than using one function per state. Faster than using generators.
Faster than using code objects.
Some, possibly minor, problems:
1. The generated code is ugly.
2. The generated code can be quite large, depending on th
Adding a continue statemtent after the yield statements yields :-) a
speed increase. Still not as good as functions though. (about 30% slower)
Cheers,
Carl
Carl Cerecke wrote:
> Carl Cerecke wrote:
> Generator FSM done properly (well, better anyway). They are still almost
> twice a
Carl Cerecke wrote:
> Fredrik Lundh wrote:
>
>> 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
Fredrik Lundh wrote:
> 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 ju
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 ove
Randall Parker wrote:
> Steve,
>
> This is an aside: I'd love to see someone implement in Python a
> framework similar to the Quantum Leaps Quantum Framework for
> event-driven programming. I think Python has some features that lend
> themselves to a neater implementation than what can be done in
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 ev
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"; stat
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
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
Steven Bethard wrote:
> Carl Cerecke wrote:
>
>> Python has no goto.
>
>
> Not in the standard library. You have to download the module:
> http://www.entrian.com/goto/
Haha! Sure. But have you seen how it's implemented? I don't think it
will win many pe
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 consu
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
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
27;t take as long
to write!
Here it is:
#!/usr/bin/env python
# Copyright 2005 Carl Cerecke
# Permission is granted to use, copy, modify, and distribute the code
and/or derived works of the code.
#import psyco
#psyco.full()
import copy
def compute_edge_cells():
global edge_ls
21 matches
Mail list logo
