e problem is the real time execution of the program (in class2) requires
an instant check to be performed and that cannot wait until the current
loop instructions finish, and I want is to break out of the outer while
loop if the event is on without further checking any other condition.
for n
from outside the loop. While doing so, I have bumped
against some common (I think) use-cases which seem to have no elegant solution
anymore. At least I can't find one that seems "pythonic" or "correct".
Problem: Before 3.10, asyncio.get_event_loop() was a convenient way to
Kiran Kumar wrote:
Hi.
Pls check on below poython 3.9.x code & suggest how can i keep the string
intactst in 2nd loop... ? these are aws ec2 ids
Don't loop through it then.
--
https://mail.python.org/mailman/listinfo/python-list
Hi.
Pls check on below poython 3.9.x code & suggest how can i keep the string
intactst in 2nd loop... ? these are aws ec2 ids
>>> INSTANCE_ID = ['i-0dccf1ede229ce1','i-0285506fee62051']
>>> for i in INSTANCE_ID:
... print (i)
...
i-0dccf1ede229ce1
execv. The Python program
> continues to run concurrently in a while True loop, and responds to requests
> from C at intervals, and continues to run until it receives a signal from C
> to exit. C sends signals to Python, then waits to receive data back from
> Python. My problem was that
On 2021-12-08 18:11:48 +0100, Jen Kris via Python-list wrote:
> To recap, I'm using a pair of named pipes for IPC between C and
> Python. Python runs as a child process after fork-execv. The Python
> program continues to run concurrently in a while True loop, and
> responds to r
On 08Dec2021 18:11, Jen Kris wrote:
>Python must terminate its write strings with \n, or read will block in
>C waiting for something that never comes.
There are two aspects to this:
- if upstream is rding "lines of text" then you need a newline to
terminate the lines
- you (probably) should f
nyone has a better solution I would
appreciate any feedback.
To recap, I'm using a pair of named pipes for IPC between C and Python. Python
runs as a child process after fork-execv. The Python program continues to run
concurrently in a while True loop, and responds to requests from C at
> On 6 Dec 2021, at 21:05, Jen Kris wrote:
>
> Here is what I don't understand from what you said. "The child process is
> created with a single thread—the one that called fork()." To me that implies
> that the thread that called fork() is the same thread as the child process.
> I guess y
Here is what I don't understand from what you said. "The child process is
created with a single thread—the one that called fork()." To me that implies
that the thread that called fork() is the same thread as the child process. I
guess you're talking about the distinction between logical threa
> On 6 Dec 2021, at 17:09, Jen Kris via Python-list
> wrote:
>
> I can't find any support for your comment that "Fork creates a new
> process and therefore also a new thread." From the Linux man pages
> https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is
> created w
On Tue, Dec 7, 2021 at 4:10 AM Jen Kris via Python-list
wrote:
>
> I can't find any support for your comment that "Fork creates a new
> process and therefore also a new thread." From the Linux man pages
> https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is
> created wit
I can't find any support for your comment that "Fork creates a new
process and therefore also a new thread." From the Linux man pages
https://www.man7.org/linux/man-pages/man2/fork.2.html, "The child process is
created with a single thread—the one that called fork()."
I have a one-core one-thr
>> Thanks for your comments.
>>
>> I put the Python program on its own pthread, and call a small C program to
>> fork-execv to call the Python program as a child process.
>
> What do you mean by putting python in it’s own pthread?
> Are you embedding python
On 2021-12-06 00:51:13 +0100, Jen Kris via Python-list wrote:
> The C program creates two threads (using pthreads), one for itself and
> one for the child process. On creation, the second pthread is pointed
> to a C program that calls fork-execv to run the Python program. That
> way Python runs o
on program on its own pthread, and call a small C program to
>> fork-execv to call the Python program as a child process.
>>
>
> What do you mean by putting python in it’s own pthread?
> Are you embedding python in an other program?
>
> Barry
>
>
>
>> I re
own pthread?
Are you embedding python in an other program?
Barry
> I revised the Python program to be a multiprocessing loop using the Python
> multiprocessing module. That bypasses the GIL and allows Python to run
> concurrently with C. So far so good.
>
> Next I will use Linux pip
Thanks for your comments.
I put the Python program on its own pthread, and call a small C program to
fork-execv to call the Python program as a child process. I revised the Python
program to be a multiprocessing loop using the Python multiprocessing module.
That bypasses the GIL and allows
that just does the fork and exec of a python
program to test out your assumptions?
If not I recommend that you do.
Barry
>
>
>
> Nov 30, 2021, 11:42 by ba...@barrys-emacs.org:
>
>
>> On 29 Nov 2021, at 22:31, Jen Kris > <mailto:jenk...@tutanota.com>> wrote:
>>
>
>
>
>> On 29 Nov 2021, at 22:31, Jen Kris <>> jenk...@tutanota.com>> > wrote:
>>
>> Thanks to you and Cameron for your replies. The C side has an epoll_ctl
>> set, but no event loop to handle it yet. I'm putting that in now with a
>
> On 29 Nov 2021, at 22:31, Jen Kris wrote:
>
> Thanks to you and Cameron for your replies. The C side has an epoll_ctl set,
> but no event loop to handle it yet. I'm putting that in now with a pipe
> write in Python-- as Cameron pointed out that is the likely source
Thanks to you and Cameron for your replies. The C side has an epoll_ctl set,
but no event loop to handle it yet. I'm putting that in now with a pipe write
in Python-- as Cameron pointed out that is the likely source of blocking on C.
The pipes are opened as rdwr in Python because t
poll().
>
> The Python child process is in a while True loop, which is intended to keep
> it running while the parent process proceeds, and perform functions for the C
> program only at intervals when the parent sends data to the child -- similar
> to a daemon process.
>
>
poll().
>
> The Python child process is in a while True loop, which is intended to keep
> it running while the parent process proceeds, and perform functions for the C
> program only at intervals when the parent sends data to the child -- similar
> to a daemon process.
>
>
in a while True loop, which is intended to keep it
>running while the parent process proceeds, and perform functions for the C
>program only at intervals when the parent sends data to the child -- similar
>to a daemon process.
>
>The C process writes to its end of the pipe and the
I have a C program that forks to create a child process and uses execv to call
a Python program. The Python program communicates with the parent process (in
C) through a FIFO pipe monitored with epoll().
The Python child process is in a while True loop, which is intended to keep it
running
worry
the original might be changed out from under.
My apologies if it was understood to mean I had shown it was copied.
-Original Message-
From: Python-list On
Behalf Of Stefan Ram
Sent: Tuesday, October 12, 2021 9:49 PM
To: python-list@python.org
Subject: Re: sum() vs. loop
&quo
On Mon, 11 Oct 2021 at 23:00, Christian Gollwitzer wrote:
>
> Am 10.10.21 um 10:49 schrieb Steve Keller:
> > I have found the sum() function to be much slower than to loop over the
> > operands myself:
> >
> > def sum_products(seq1, seq2):
> > return s
On Wed, Oct 13, 2021 at 12:36 PM Avi Gross via Python-list
wrote:
>
> Alan,
>
> I am also wondering about that zip() function call to bind the two lists
> into a sort of iterator object. Presumably that calls the iterator N times.
> I did a test where I made two list called A and B and used zip to
.
-Original Message-
From: Python-list On
Behalf Of Alan Gauld
Sent: Tuesday, October 12, 2021 6:56 PM
To: python-list@python.org
Subject: Fwd: Re: sum() vs. loop
On 10/10/2021 09:49, Steve Keller wrote:
> I have found the sum() function to be much slower than to loop over
> the op
Am 12.10.21 um 05:41 schrieb Dan Stromberg:
On Mon, Oct 11, 2021 at 2:54 PM Steve Keller wrote:
I have found the sum() function to be much slower than to loop over the
operands myself:
def sum_products(seq1, seq2):
return sum([a * b for a, b in zip(seq1, seq2)])
def sum_products2(seq1
On 10/10/2021 09:49, Steve Keller wrote:
> I have found the sum() function to be much slower than to loop over the
> operands myself:
>
> def sum_products(seq1, seq2):
> return sum([a * b for a, b in zip(seq1, seq2)])
>
> def sum_products2(seq1, seq2):
> sum = 0
>
On Mon, Oct 11, 2021 at 2:54 PM Steve Keller wrote:
> I have found the sum() function to be much slower than to loop over the
> operands myself:
>
> def sum_products(seq1, seq2):
> return sum([a * b for a, b in zip(seq1, seq2)])
>
> def sum_products2(seq1, seq2):
>
ve 1000 entries each
> (with float entries).
>
> However, in any case, the direct for-loop still is fastest.
> Maybe, calling "next()" (actually, "PyIter_Next" in C) on
> an iterator has some overhead compared to just evaluating
> an expression in a loo
On Tue, Oct 12, 2021 at 8:55 AM Steve Keller wrote:
>
> I have found the sum() function to be much slower than to loop over the
> operands myself:
>
> def sum_products(seq1, seq2):
> return sum([a * b for a, b in zip(seq1, seq2)])
>
> def sum_products2(seq1, seq2):
&
, of course. Much cleaner and I should have seen that myself.
Thanks.
BUT
> (untested) ?
I have tested it and with () instead of [] it's even slower:
explicit loop: 37s ± .5s
sum([...]) 44s ± .5s
sum((...)) 47.5s ± .5s
Now completely surprised.
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Am 10.10.21 um 10:49 schrieb Steve Keller:
I have found the sum() function to be much slower than to loop over the
operands myself:
def sum_products(seq1, seq2):
return sum([a * b for a, b in zip(seq1, seq2)])
def sum_products2(seq1, seq2):
sum = 0
for a, b in zip(seq1, seq2
I have found the sum() function to be much slower than to loop over the
operands myself:
def sum_products(seq1, seq2):
return sum([a * b for a, b in zip(seq1, seq2)])
def sum_products2(seq1, seq2):
sum = 0
for a, b in zip(seq1, seq2):
sum += a * b
return sum
In a program
dn writes:
[...]
> Further, if you look at the OP's original solution, it only publishes
> the last pair, ie the match, without mention of the list of non-matches.
> Was it perhaps only a means of testing the solution?
It was a means of showing the student that indeed they obtained a match.
If
On 11/09/2021 10:09, dn via Python-list wrote:
The stated requirement is: "I'd like to get the number of times I
tried". Given such: why bother with returning any of the pairs of values?
Indeed, if that's the requirement, then you can do even better, noting
that the probability of getting a
On 2021-09-08 13:07:47 +1200, Greg Ewing wrote:
> On 8/09/21 2:53 am, Grant Edwards wrote:
> >#define IF if (
> >#define THEN ) {
> >#define ELSE } else {
> >#define ENDIF }
>
> I gather that early versions of some of the Unix utilities were
> written by someone who liked using mac
On 11/09/2021 18.03, Chris Angelico wrote:
> On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
> wrote:
>>
>> On 31/08/2021 01.50, Chris Angelico wrote:
>>> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
>>> wrote:
> def how_many_times():
> x, y = 0, 1
> c = 0
> wh
On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
wrote:
>
> On 31/08/2021 01.50, Chris Angelico wrote:
> > On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> > wrote:
> >>
> >>> def how_many_times():
> >>> x, y = 0, 1
> >>> c = 0
> >>> while x != y:
> >>> c = c + 1
> >>> x, y = rol
On 31/08/2021 01.50, Chris Angelico wrote:
> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> wrote:
>>
>>> def how_many_times():
>>> x, y = 0, 1
>>> c = 0
>>> while x != y:
>>> c = c + 1
>>> x, y = roll()
>>> return c, (x, y)
>>
>> Since I haven't seen it used in answers yet, her
On Wed, 8 Sep 2021 16:32:45 - (UTC), Grant Edwards
declaimed the following:
>On 2021-09-08, Dennis Lee Bieber wrote:
>
>> I spent close to 20 years (80s-90s) maintaining the /output/ of such
>> a preprocessor.
>
>Ouch. I hope it paid well. ;)
Only if one ignores the bloody cost of a
On Wed, 8 Sep 2021 14:46:28 - (UTC), Grant Edwards
declaimed the following:
>On 2021-09-08, charles hottel wrote:
>
>> So what do yoy think or feel about a language like RATFOR (Rational
>> FORTRAN) which was implemented as macros? Should they instead have
>> simply adapted themselves to
On 2021-09-08, Dennis Lee Bieber wrote:
> I spent close to 20 years (80s-90s) maintaining the /output/ of such
> a preprocessor.
Ouch. I hope it paid well. ;)
Back when I did a lot of TeX/LaTeX stuff on VMS, I used to make
occasional fixes and add (very minor) features to one of the dvi
handlin
customize Python to a point where it does things in fairly
hidden ways too. There are no promises of purity.
What this particular discussion began with was much lower level and about
various ways of writing a while loop within very basic Python and seems to
be heading away into discussions of other
On Wed, 8 Sep 2021 00:24:44 +0100, Alan Gauld via Python-list
declaimed the following:
>
>That was quite common in C before it became popular(early/mid 80s).
>I've seen Pascal, Algol and Coral macro sets in use.
>You could even download pre-written ones from various
>bulletin boards (remember the
On 2021-09-08, charles hottel wrote:
> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros?
The RATFOR implementations I've seen weren't done using macros. It was
a preprocessor, yes. But it generates code for the various structured
sta
On 2021-09-08, charles hottel wrote:
> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros? Should they instead have
> simply adapted themselves to FORTRAN?
That's an interesting question. If the langauge is complete,
well-defined, an
7, 2021 9:08 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice
On 8/09/21 2:53 am, Grant Edwards wrote:
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...
I gather that early versions of some of the Unix utilities
another object means you over-rode the meaning of
+= for instance.
-Original Message-
From: Python-list On
Behalf Of Richard Damon
Sent: Tuesday, September 7, 2021 10:09 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice
On 9/7/21 3:51 PM, Avi Gross via
On 9/7/21 3:51 PM, Avi Gross via Python-list wrote:
> and similarly changes any function imported directly
> to also be fully qualified.
One danger with this is that it can actual change the behavior of the
program. Maybe more likely with global objects than functions, but still
an issue.
Remembe
@python.org
Subject: Re: on writing a while loop for rolling two dice
On 8/09/21 2:53 am, Grant Edwards wrote:
>#define IF if (
>#define THEN ) {
>#define ELSE } else {
>#define ENDIF }
>...
I gather that early versions of some of the Unix utilities were written by
so
On 8/09/21 2:53 am, Grant Edwards wrote:
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...
I gather that early versions of some of the Unix utilities were
written by someone who liked using macros to make C resemble Algol.
I guess you can get away with t
On 07/09/2021 15:53, Grant Edwards wrote:
> I remember engineering manager I worked with about 35 years ago who
> used a set of C macros to try to make his code look as much like BASIC
> as possible:
>
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...
alister via Python-list
Sent: Tuesday, September 7, 2021 2:58 PM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice
On Tue, 07 Sep 2021 14:53:29 +, Grant Edwards wrote:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" writes:
>&g
On Tue, 7 Sep 2021 16:08:04 +1200, Greg Ewing
declaimed the following:
>On 7/09/21 11:38 am, Avi Gross wrote:
>
>> #define INDEFINITELY_LOOP while (true)
>>
>> So, how to do something like that in python, is a challenge left to the user
>> ?
>
>def hell_frozen_over():
> return False
>
>whil
Grant Edwards writes:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
>>>INDEFINITELY_LOOP with valid C
On Tue, 07 Sep 2021 14:53:29 +, Grant Edwards wrote:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
On 2021-09-06, Stefan Ram wrote:
> "Avi Gross" writes:
>> In languages like C/C++ there are people who make up macros like:
>>#define INDEFINITELY_LOOP while (true)
>>Or something like that and then allow the preprocessor to replace
>>INDEFINITELY_LOOP with valid C code.
>
> Those usually are
On 7/09/21 11:38 am, Avi Gross wrote:
#define INDEFINITELY_LOOP while (true)
So, how to do something like that in python, is a challenge left to the user 😉
def hell_frozen_over():
return False
while not hell_frozen_over():
--
Greg
--
https://mail.python.org/mailman/listinfo/py
ython-list@python.org
Subject: Re: on writing a while loop for rolling two dice
"Avi Gross" writes:
> In languages like C/C++ there are people who make up macros like:
>#define INDEFINITELY_LOOP while (true)
>Or something like that and then allow the preprocessor to replace
>IND
RESEND with clarification!
On Mon, 6 Sep 2021 20:11:41 -0400, Avi Gross via Python-list
declaimed the following:
>changing. Ages ago we had code that processed MTA headers and every time we
>had a meeting of standards bodies, we kept adding ever more headers and
Why did my mind immedi
On Mon, 6 Sep 2021 20:11:41 -0400, Avi Gross via Python-list
declaimed the following:
>changing. Ages ago we had code that processed MTA headers and every time we
>had a meeting of standards bodies, we kept adding ever more headers and
Why did my mind immediately flash on "The Man Who Ne
():
print("repeating ...")
The above gives me a nice infinite loop, with the second one looking like a
normal loop but actually doing nothing much.
-Original Message-
From: Python-list On
Behalf Of 2qdxy4rzwzuui...@potatochowder.com
Sent: Monday, September 6, 2021 8:28 PM
To:
On 2021-09-06 at 20:11:41 -0400,
Avi Gross via Python-list wrote:
> And in the python version, has anyone made a generator that returned
> NULL or the like so you can say uselessly:
>
> for ( _ in forever() ) ...
while "forever":
...
--
https://mail.python.org/mailman/listinfo/pyth
are checking what types they are working with and perhaps
converting to others or need to create objects with lots of dunders, can
also make it error prone.
Looking at our forever loop discussion, how often are the contents of the
loop written with multiple terminating parts within the loop body
I actually like it if a language lets you spell out your intention, although
adding many keywords is not a plus.
So, yes something like:
loop
...
end loop;
Is appealing as it makes clear the decision on when to exit the loop must be
within the loop (or till
ion, consider languages with "repeat / until"...
"do / while" repeats so long as the condition evaluates to "true";
"repeat / until" /exits/ when the condition evaluates to "true".
Then... there is Ada...
While
essage-
From: Python-list On
Behalf Of Hope Rouselle
Sent: Thursday, September 2, 2021 10:42 AM
To: python-list@python.org
Subject: Re: on writing a while loop for rolling two dice
David Raymond writes:
>> def how_many_times():
>> x, y = 0, 1
>> c = 0
>> while x
"Michael F. Stemper" writes:
> On 04/09/2021 08.53, Hope Rouselle wrote:
>> Chris Angelico writes:
>
>>> And at this point, it's looking pretty much identical to the for loop
>>> version. Ultimately, they're all the same and you can pick a
-start->8---
>> >> def how_many_times():
>> >> x, y = 0, 1
>> >> c = 0
>> >> while x != y:
>> >> c = c + 1
>> >> x, y = roll()
>> >> return c, (x, y)
>> >
>> >>
>
ed was the equal volume of work
>> dedicated to while loops and for loops --- so I decided to compared
>> which appeared more often in a certain sample of well-written Python
>> code. It turns out the for loop was much more frequent. Students have
>> been reporting too much
On 04/09/2021 08.53, Hope Rouselle wrote:
Chris Angelico writes:
And at this point, it's looking pretty much identical to the for loop
version. Ultimately, they're all the same and you can pick and choose
elements from each of them.
I see. That's why C must have added th
s():
> >> x, y = 0, 1
> >> c = 0
> >> while x != y:
> >> c = c + 1
> >> x, y = roll()
> >> return c, (x, y)
> >
> >>
> >> Why am I unhappy? I'm wish I could confine x, y to the while loop.
> >>
def how_many_times():
x, y = 0, 1
c = 0
while x != y:
c = c + 1
x, y = roll()
return c, (x, y)
Since I haven't seen it used in answers yet, here's another option using our
new walrus operator
def how_many_times():
roll_count = 1
while (rolls := roll())[0] != rol
k. If a
student ever turns in an abomination like this, you can be extremely
confident that it was copied from some programming site/list.
Especially since I've used the two-arg version of iter() in there -
that's quite a rarity.
Hm.
My mind is straying to evil things.
The two-arg ite
ted to while loops and for loops --- so I decided to compared
> which appeared more often in a certain sample of well-written Python
> code. It turns out the for loop was much more frequent. Students have
> been reporting too much work in too little time, so I decided to reduce
> the n
Chris Angelico writes:
> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> wrote:
>>
>> > def how_many_times():
>> > x, y = 0, 1
>> > c = 0
>> > while x != y:
>> > c = c + 1
>> > x, y = roll()
>> > return c, (x, y)
>>
>> Since I haven't seen it used in answers yet, here's another
on using our
> new walrus operator
>
> def how_many_times():
> roll_count = 1
> while (rolls := roll())[0] != rolls[1]:
> roll_count += 1
> return (roll_count, rolls)
That's nice, although it doesn't seem more readable to a novice seeing a
while for the first ti
c + 1
>> x, y = roll()
>> return c, (x, y)
>
>>
>> Why am I unhappy? I'm wish I could confine x, y to the while loop. The
>> introduction of ``x, y = 0, 1'' must feel like a trick to a novice. How
>> would you write this?
>
>>
On 30/08/2021 06:17, dn via Python-list wrote:
OTOH the simulation of rolling n-number of dice, as would happen in the
real-world, would be broken by making the computer's algorithm more
efficient (rolling until the first non-equal value is 'found'). Does
that mean the realism of the model dies?
On Tue, Aug 31, 2021 at 12:28 AM Peter Otten <__pete...@web.de> wrote:
>
> On 30/08/2021 15:50, Chris Angelico wrote:
>
> > def how_many_times():
> > return next((count, rolls) for count, rolls in
> > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
>
>
> That's certainly the most Coun
On 30/08/2021 15:50, Chris Angelico wrote:
def how_many_times():
return next((count, rolls) for count, rolls in
enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
That's certainly the most Counter-intuitive version so far;)
Do I get bonus points for it being a one-liner that doe
On Mon, Aug 30, 2021 at 11:13 PM David Raymond wrote:
>
> > def how_many_times():
> > x, y = 0, 1
> > c = 0
> > while x != y:
> > c = c + 1
> > x, y = roll()
> > return c, (x, y)
>
> Since I haven't seen it used in answers yet, here's another option using our
> new walrus operator
> def how_many_times():
> x, y = 0, 1
> c = 0
> while x != y:
> c = c + 1
> x, y = roll()
> return c, (x, y)
Since I haven't seen it used in answers yet, here's another option using our
new walrus operator
def how_many_times():
roll_count = 1
while (rolls := roll())[0] !=
Each code-unit should do one job, and do it well!
SRP...
>> Efficiency:
>> - wonder how max( d ) == min( d ) compares for speed with the set() type
>> constructor?
>
> I did the simplest thing, speed was not a consideration. If it is, and
> dies (sorry for that) is large I&#
On Mon, Aug 30, 2021 at 9:53 AM dn via Python-list
wrote:
>
> On 29/08/2021 22.24, Chris Angelico wrote:
> > On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
> > wrote:
> >> Efficiency:
> >> - wonder how max( d ) == min( d ) compares for speed with the set() type
> >> constructor?
> >
> > That
On 29/08/2021 22.24, Chris Angelico wrote:
> On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
> wrote:
>> Efficiency:
>> - wonder how max( d ) == min( d ) compares for speed with the set() type
>> constructor?
>
> That may or may not be an improvement.
>
>> - alternately len( d ) < 2?
>> - or
for x in d) # don't mind one duplicate test
For smaller numbers of dice I'd unpack (first, *rest) inside the for
loop. But it's a trade-off, you' have to measure if/when it's better to
go through the whole tuple in C.
- alternately len( d ) < 2?
- or len( d ) - 1
On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
wrote:
> Efficiency:
> - wonder how max( d ) == min( d ) compares for speed with the set() type
> constructor?
That may or may not be an improvement.
> - alternately len( d ) < 2?
> - or len( d ) - 1 coerced to a boolean by the if?
Neither of t
On 29/08/2021 20.06, Peter Otten wrote:
...
> OK, maybe a bit complicated... but does it pay off if you want to
> generalize?
>
def roll_die(faces):
> while True: yield random.randrange(1, 1 + faces)
>
def hmt(faces, dies):
> for c, d in enumerate(zip(*[roll_die(faces)]*dies), 1
On 28/08/2021 14:00, Hope Rouselle wrote:
def how_many_times():
x, y = 0, 1
c = 0
while x != y:
c = c + 1
x, y = roll()
return c, (x, y)
--8<---cut here---end--->8---
Why am I unhappy? I'm wish I could confine x, y to the
And there is the ever popular recursive version you call with no while loop
in sight. And, oddly, no variable declared in your main body:
# CODE START ---
import random
def roll2():
return random.randint(1,6), random.randint(1,6)
def roll_equal(counter):
first, second = roll2
t, I'm surprised ``outcome'' is still a valid name at the
> return-statement. Wasn't it defined inside the while?
If that really bugs you just replace the break with the return.
>>> if outcome[ 0 ]== outcome[ 1 ]:
>>>return roll_count, outco
= 0
while x != y:
c = c + 1
x, y = roll()
return c, (x, y)
--8<---cut here---end--->8---
Why am I unhappy? I'm wish I could confine x, y to the while loop. The
introduction of ``x, y = 0, 1'' must feel like a trick to a
x, y)
>
> Why am I unhappy? I'm wish I could confine x, y to the while loop. The
> introduction of ``x, y = 0, 1'' must feel like a trick to a novice. How
> would you write this?
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> """Rolls two d
Hope Rouselle writes:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Hope Rouselle writes:
>>>How would you write this?
>>
>> """Rolls two dice until both yield the same value.
>> Returns the number of times the two dice were rolled
>> and the final value yielded."""
>> roll_count = 0
>> wh
1 - 100 of 3607 matches
Mail list logo
