Has anyone considered the idea of adding a "do at least once" loop to Python?
This is frequently referred to as a do ... while or repeat ... until.
At the moment, it's a bit of a hack to achieve this in that we do a 'while
True: ( do thing ; if cond: ( break ) )'. Since I don't know how to forma
As you probably suspect, yes, it comes up every couple of years. Here's
one of the recent threads (there are more, just search for 'until' in the
archives), that might give you some ideas for how this discussion will
progress. :)
https://mail.python.org/archives/list/[email protected]/threa
I have use cases for "do exactly once".
Basically a sequence of actions which can be broken off (when something
goes wrong and the whole process should be aborted, or when something
succeeds and there is no need to try alternatives) at various points
with `break`. Thus avoiding multiple if...t
How does `try/except` (with raise AppropriateException inside the block)
compare to a len-1 loop?Om On Tue, 01 Mar 2022 10:04:31 -0600
[email protected] wrote
I have use cases for "do exactly once".
Basically a sequence of actions which can be broken off (when
If you don't like:
while True:
...
if whatever:
break
One thing I've seen people do is:
condition = True
while condition:
...
condition = whatever
You can use it if you really hate `while True` loops with `break`.
___
Python-id
Along similar lines, you could also use the fact that Python does
lazy-evaluation to make a do-while which forward-references variables:
```
enter_dw = True
while enter_dw or (condition_with_vars_not_defined_the_first_time_through):
enter_dw = False
define_those_vars()
```
Sketch of a us
On Tue, Mar 01, 2022 at 04:04:31PM +, Rob Cliffe via Python-ideas wrote:
> I have use cases for "do exactly once".
> Basically a sequence of actions which can be broken off (when something
> goes wrong and the whole process should be aborted, or when something
> succeeds and there is no need
On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
>
> On Tue, Mar 01, 2022 at 04:04:31PM +, Rob Cliffe via Python-ideas wrote:
>
> > I have use cases for "do exactly once".
> > Basically a sequence of actions which can be broken off (when something
> > goes wrong and the whole process should
Without testing, I am sure it would be slower.
I suppose it would be reasonable if exceptions are raised in multiple
places and the exceptions were given meaningful names.
Best wishes
Rob Cliffe
On 01/03/2022 17:22, om wrote:
How does `try/except` (with raise AppropriateException inside the
bl
On Wed, 2 Mar 2022 at 09:58, Rob Cliffe via Python-ideas
wrote:
>
> Without testing, I am sure it would be slower.
That's a trap to be careful of. Test! :)
ChrisA
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
On Tue, Mar 01, 2022 at 04:04:31PM +, Rob Cliffe via Python-ideas wrote:
I have use cases for "do exactly once".
Basically a sequence of actions which can be broken off (when something
goes wr
On 01/03/2022 22:25, Chris Angelico wrote:
class MyBreak(Exception):
pass
try:
do_this()
if condition: raise MyBreak
do_that()
if condition: raise MyBreak
do_next_step()
if condition: raise MyBreak
do_last_step
On Tue, Mar 1, 2022 at 2:23 PM Steven D'Aprano wrote:
> try:
> do_this()
> if condition: raise MyBreak
> do_that()
> if condition: raise MyBreak
> do_next_step()
> if condition: raise MyBreak
> do_last_step()
> except MyBreak:
>
On 01/03/2022 23:57, Ben Rudiak-Gould wrote:
On Tue, Mar 1, 2022 at 2:23 PM Steven D'Aprano
wrote:
try:
do_this()
if condition: raise MyBreak
do_that()
if condition: raise MyBreak
do_next_step()
if condition: rai
On Tue, Mar 01, 2022 at 11:50:42PM +, Rob Cliffe via Python-ideas wrote:
> It doesn't feel right to me to use exceptions purely to direct control
> flow. YMMV.
Then Python is the wrong language for you, because it uses exceptions to
direct control flow *wink*
The iteration protocol uses S
On 2/03/22 12:50 pm, Rob Cliffe via Python-ideas wrote:
As I see it, the original meaning of an exception (in whatever language)
is "something unexpected has happened" or "something has gone wrong".
Using exceptions for flow control has always been acceptable in
Python. The iterator protocol re
On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 01/03/2022 22:25, Chris Angelico wrote:
> > On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
> >> On Tue, Mar 01, 2022 at 04:04:31PM +, Rob Cliffe via Python-ideas
> >> wrote:
> >>
> >>> I have use cases for "do ex
I'm sorry for reposting, but this message got stuck in moderation
approval for 5 days so I figured I should try again.
I'd like to propose extending the for statement to include conditionals
akin to comprehensions in order to simplify for loop statements:
`for .. in .. if ..:`
E.g.
On 02/03/2022 01:02, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
wrote:
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano wrote:
On Tue, Mar 01, 2022 at 04:04:31PM +, Rob Cliffe via Python-ideas wrote:
I have
Very strong +1.
On Wed, 2022-03-02 at 02:28 +0100, Svein Seldal wrote:
> I'm sorry for reposting, but this message got stuck in moderation
> approval for 5 days so I figured I should try again.
>
>
> I'd like to propose extending the for statement to include
> conditionals
> akin to comprehens
On Wed, 2 Mar 2022 at 12:33, Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 02/03/2022 01:02, Chris Angelico wrote:
> > On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
> > wrote:
> >>
> >>
> >> On 01/03/2022 22:25, Chris Angelico wrote:
> >>> On Wed, 2 Mar 2022 at 09:24, Steven D'Aprano
On Wed, Mar 02, 2022 at 02:28:33AM +0100, Svein Seldal wrote:
> for x in y if x in c:
> some_op(x)
What does this new syntax give us that we don't already have with this?
for x in y
if x in c:
some_op(x)
or the other multiple ways of writing the equivalent co
1. It aligns with existing syntax in list comprehensions and generator
expressions.
2. In probably majority of cases it would be more readable to me;
"iterate over iterable for items meeting condition:".
3. Could it be easier to optimize an explicit filter expression to
improve iteration performanc
-1. Extra complexity for no benefit. Attractive nuisance to making overly
complex statement lines.
On Tue, Mar 1, 2022, 8:31 PM Svein Seldal wrote:
> I'm sorry for reposting, but this message got stuck in moderation
> approval for 5 days so I figured I should try again.
>
>
> I'd like to propose
+1
This is just a small improvement, but worthwhile. It's intuitive IMO to be
able to use similar filtering expressions to comprehensions at the top of a
for loop.
Here's an example:
# get the Hadoop version by scanning pyspark jars.
# Vague attribution:
https://stackoverflow.com/a/50242383
for
On Tue, Mar 1, 2022 at 6:43 PM Steven D'Aprano wrote:
> > for x in y if x in c:
> > some_op(x)
>
> What does this new syntax give us that we don't already have with this?
>
> for x in y
> if x in c:
> some_op(x)
>
I think it's really the equivalent of
for x
On Tue, Mar 01, 2022 at 10:40:06PM -0500, Michael Smith wrote:
> +1
>
> This is just a small improvement, but worthwhile. It's intuitive IMO to be
> able to use similar filtering expressions to comprehensions at the top of a
> for loop.
Good news! We have been able to use filtering conditions at
On Wed, 2 Mar 2022 at 09:58, Rob Cliffe via Python-ideas
wrote:
Without testing, I am sure it would be slower.
Does that mean if you do test it, it'll be faster? :-)
--
Greg
___
Python-ideas mailing list -- [email protected]
To unsubscribe se
Steven D'Aprano writes:
> On Wed, Mar 02, 2022 at 02:28:33AM +0100, Svein Seldal wrote:
>
> > for x in y if x in c:
> > some_op(x)
>
> What does this new syntax give us that we don't already have with this?
>
> for x in y
> if x in c:
> some_op(x)
I
On Wed, 2 Mar 2022 at 17:08, Greg Ewing wrote:
>
> > On Wed, 2 Mar 2022 at 09:58, Rob Cliffe via Python-ideas
> > wrote:
> >>
> >> Without testing, I am sure it would be slower.
>
> Does that mean if you do test it, it'll be faster? :-)
>
Wait, the reason my code is slow is that I don't have uni
On 02/03/2022 02:01, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 12:33, Rob Cliffe via Python-ideas
wrote:
On 02/03/2022 01:02, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 10:32, Rob Cliffe via Python-ideas
wrote:
On 01/03/2022 22:25, Chris Angelico wrote:
On Wed, 2 Mar 2022 at 09:24,
On Wed, 2 Mar 2022 at 18:35, Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 02/03/2022 02:01, Chris Angelico wrote:
> > This doesn't obscure the control flow any more than a 'while' loop,
> It certainly does! I see a decorated function. Nothing tells me that
> the decorator actually *calls* the f
32 matches
Mail list logo
