[Python-ideas] Re: repeat until

[Chris Angelico]

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 function.  This really is obscurantism.

"while True:" doesn't say that the loop will be executed at most once.
How is this any worse? Given that you get to choose the name of the
function AND the name of the decorator, I hardly think that you're
really losing out here/

> >> (b) AFAICS If you want to alter variables local to the outer function,
> >> you have to declare them non-local in the inner function.
> > Yes, that's true. But that's not very common.
> That's your opinion.  It happens in my code.

Can you post an example where you need a large number of nonlocals? A
single nonlocal is hardly a major problem.

> > This is also true, but for the use-case you're describing, where you
> > want to break at arbitrary points, it seems highly likely that you'd
> > want to initialize it to some default. So in theory, this is a
> > problem, but in practice, almost never.
> AFAIK it doesn't happen in my code, but I can easily imagine that it might.

Like I said, in theory a problem, in practice, not. I have *never
once* run into this; in fact, I had to quickly check a couple of
options to confirm that they indeed didn't work, because I've never
been in a position of needing that.

> >>   for _ in '1':   # Execute this 'loop' once only (break once we
> >> know how to ...)
> >>   
> You've not convinced me that there is anything better than the above
> (for my needs).
> No new idioms, no opaque decorators, no obscuring the control flow, no
> need to worry about variable scopes.
> I would like a better way to spell it, but that's a minor cosmetic issue.

Very minor. You have quite a number of alternatives to choose from,
and not one of them needs new syntax.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G3XN3MRVO3S2672RRGLB2WEXG45PAITJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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, 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 be aborted, or when something
succeeds and there is no need to try alternatives) at various points
with `break`.

   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()
   except MyBreak:
   pass


All this is assuming that you can't refactor it into a function and
'return' each time. That's also a viable option, where applicable.

Yes, it is a viable (even preferable) option when applicable.
But there are times when it is not applicable, or is very inconvenient.
E.g. when a long list of local variables have to be turned into long
verbose error-prone and hard-to maintain lists of parameters and return
values (if the code is factored off into a function).

Inner functions are spectacular for that :)



Well, they can do the job.  'spectacular' is not a word I would use:
(a) you have to define your inner function, then call it:
  def innerfunc():
  
  innerfunc()
  which obscures the control flow.

If this is something you find yourself doing a lot, it wouldn't be
hard to make a "breakable" decorator:

def breakable(f): return f()

def do_lots_of_work():
 x, y, z = 1, 2, "spam"
 @breakable
 def inner():
 if x < y: return
 print(z)
 ...

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 function.  This really is obscurantism.

  or
any other breakable construct you might come up with. It has a header
that says what it does, and then you have the body, which ends at the
unindent.


(b) AFAICS If you want to alter variables local to the outer function,
you have to declare them non-local in the inner function.

Yes, that's true. But that's not very common.

That's your opinion.  It happens in my code.

  Bear in mind that the
inner function can 'return x' to pass a value back, which can easily
be captured when you call it (in the decorator example I gave, it's
automatically captured into the name of the block), and of course you
can mutate any object owned by the outer scope. Chances are you'll
never have more than a small handful of nonlocals in the inner
function.

It's still extra boilerplate to be (mis-)managed.



(c) AFAIK you can not create identifiers in the inner function which the
outer function can "see".  Example:

  def f():
  def innerfunc():
  foo = 1
  innerfunc()
  print(foo)
f()

print(foo) fails.  You have to create foo in the outer function, then
declare it non-local:

def f():
  foo = None
  def innerfunc():
  nonlocal foo
  foo = 1
  innerfunc()
  print(foo)

f()

This "works": print(foo) prints 1.

This is also true, but for the use-case you're describing, where you
want to break at arbitrary points, it seems highly likely that you'd
want to initialize it to some default. So in theory, this is a
problem, but in practice, almost never.

AFAIK it doesn't happen in my code, but I can easily imagine that it might.



Pretty much as inconvenient as creating parameter and return lists, ISTM.
No, so far I have seen no improvement on this which I use (including a
suitable helpful comment, as below) in production code:

Not NEARLY as inconvenient in practice. I don't have absolute proof of
this, but I can assure you that when I need to break out a function in
a language that doesn't support closures (like deferring execution of
part of some code in SourcePawn - the only way is to create a
standalone function, set a timer to call the function at the right
point, and pass it al the arguments), it feels way WAY clunkier than
simply referencing variables. The main reason for this is that it's a
lot more common to *read* variables from outer scopes than to *write*
to them.


  for _ in '1':   # Execute this 'loop' once only (break once we
know how to ...)
  
You've not convinced me that there is anything better than the above 
(for my needs).
No new idioms, no opaque decorators, no obscuring the control flow, no 
need to worry about variable scopes.

I would like a better way to spell it, but that's a minor cosmetic issue.


That's also viable, and perso

[Python-ideas] Re: repeat until

[Chris Angelico]

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 unit tests? Huh.
Maybe I should get onto that.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/34UC3P4CB5FE5RX6HWQTTYD6GFZGTU43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Stephen J. Turnbull]

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)

It would actually work! (missing colon ;-)

 > I see no new functionality here. Is the only advantage that you save one 
 > line and one indent level? Both are cheap.

It's arguably consistent with comprehension syntax, which one could
argue makes learning either simpler if you already know the other.
But I'm -0.5 on this change as needless churn, and -0.5 on it because
I really don't want to invite the full comprehension syntax (with
nested "in ... if" clauses) and without it it's still not the same,
for a net "vote" of math.nextafter(-1,0).



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CHLZRWY4Q3L7A23D4NUGE6KIRKWYG3JL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Greg Ewing]

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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CUD6VCUAD7MJEXPZPHSUNGYDP2LOYWGP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Steven D'Aprano]

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 the top of a 
for loop since Python 1.5 or even earlier, back in the 1990s.

And the excellent thing about the existing syntax is that we can split 
the for loop and the filter onto separate lines for enhanced readablity, 
without needing to add extraneous parentheses and indent.

# Don't need this.
for student in students if (
mean(student.grade(subject) for subject in student.get_subjects()) 
> 0.8)
):
...

# Can do this.
for student in students:
if mean(student.grade(subject) for subject in student.get_subjects()) > 
0.8):
...

And if you are thinking right now "Huh, there is hardly any difference 
between the two, what's the big deal?" -- exactly. Outside of pretend 
code with one letter variable names, `for a in b if c`, the actual 
benefit in real code is extremely minor, if any.

In most cases you're going to split the line over two lines anyway, and 
if you find yourself worried about saving an indent, almost surely your 
code needs refactoring.


> Here's an example:
> 
> # get the Hadoop version by scanning pyspark jars.
> # Vague attribution:
> https://stackoverflow.com/a/50242383
> for path in Path("pyspark/jars")).glob("hadoop-*.jar") if not
> path.stem.startswith("hadoop-shaded-guava"):

Ironically, your one line loop and filter was word-wrapped because the 
line was too long.

Do you use black or PEP8? Do the projects you work on enforce 79 column 
or even 100 column coding standards? Then your example, with 106 
columns, will have to be split over two lines. Which is my point.

This suggestion sounds good, but in real code, you probably can't use 
it. And even if you can, it doesn't make it any easier to write loops 
with filters, or add the ability to do something new that we can't 
easily do now.

It is purely a cosmetic change, and not even a very interesting cosmetic 
change.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U5U6IOTZMN2NU3GQDO73VYCM335UYWP4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Christopher Barker]

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 in y:
if not x in c:
break
do_stuff

which to me give the proposed syntax a bit more relative strength.

I'm probably +0 -- but I do like comprehension syntax, and have often
wanted a "side effect" comprehension:

$ side_effect(item) for item in an_iterable if condition(item) $

(using $ 'cause there aren't any more brackets ...)

rather than having to write:

for item in an_iterable:
if condition(item):
side_effect(item)

To the point where I sometimes write the list comp and ignore the generated
list. NOt too huge a burden to cretae. list of None and throw it away, but
it feels wrong ;-)

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RIAZUNGF3R3KBWGFOR5G6M3BXB4AW4AX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Michael Smith]

+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 path in Path("pyspark/jars")).glob("hadoop-*.jar") if not
path.stem.startswith("hadoop-shaded-guava"):
name, _, version = path.stem.rpartition("-")
...

glob is already a filtering mechanism. It's just not *quite* flexible
enough to give just the items I want. I'd like to be able to enter the loop
with only file names of interest.

–Michael A. Smith

On Tue, Mar 1, 2022 at 21:51 Paul Bryan  wrote:

> 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 performance?
>
> On Wed, 2022-03-02 at 13:37 +1100, Steven D'Aprano wrote:
>
> 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 code?
>
> I see no new functionality here. Is the only advantage that you save one
> line and one indent level? Both are cheap.
>
> To be precise, one extra line in something which is already a multiline
> statement is essentially insignificant, and while an extra indent level
> *can* be important, if you have already used so many indents that it
> becomes important, you probably should be refactoring your code.
>
> All I see here is adding to the complexity of the parser and the
> language for no meaningful benefit. Its not even easier to read, it
> crams more on one line which in real code with meaningful variable names
> and a meanigful condition starts to get a bit long:
>
> # this line desperately needs to be split over two lines
> for student in students if mean(student.grade(subject) for subject in
> student.get_subjects()) > 0.8):
> ...
>
> When I write list comprehensions with an if condition, probably 90% of
> the time I end up moving the if condition to a second or even third line
> of the comprehension. I expect the same will apply here.
>
> To save one line for maybe 10% of my for...if constructs, I don't think
> it is worth the bother of adding yet another way to do it.
>
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KTM6XDMOMQW4W7XRDMG7S65EL34GXAZG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IP3NN773LRXG7VHEPX6BV3O2NWPK462W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[David Mertz, Ph.D.]

-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 extending the for statement to include conditionals
> akin to comprehensions in order to simplify for loop statements:
>
>  `for .. in .. if ..:`
>
> E.g.
>
>  for x in y if x in c:
>  some_op(x)
>
> which is functionally equivalent as
>
>  for x in y:
>  if x not in c:
>  continue
>  some_op(x)
>
>
> The `for .. in .. if` syntax is a well-known construct from list
> comprehension syntax [1]. Other alternative ways to do this with list
> comprehension is:
>
>  for x in (a for a in y if c):
>
> or
>
>  it = (a for a in y if c)
>  for x in it:
>
> Without having examined all use cases, I believe the same syntax should
> be applied this syntax as for asynchronous comprehensions.
>
>
> [1] PEP 202 - List Comprehensions
> [2] PEP 530 - Asynchronous Comprehensions
>
>
> Best regards,
> Svein Seldal
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7IXPROG2ANAFZTHZC4G3HRVXSKRIPXDL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Z7HOK364PZQKIPV6VK4KQ6HWV23UZHPG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Paul Bryan]

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 performance?

On Wed, 2022-03-02 at 13:37 +1100, Steven D'Aprano wrote:
> 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 code?
> 
> I see no new functionality here. Is the only advantage that you save
> one 
> line and one indent level? Both are cheap.
> 
> To be precise, one extra line in something which is already a
> multiline 
> statement is essentially insignificant, and while an extra indent
> level 
> *can* be important, if you have already used so many indents that it 
> becomes important, you probably should be refactoring your code.
> 
> All I see here is adding to the complexity of the parser and the 
> language for no meaningful benefit. Its not even easier to read, it 
> crams more on one line which in real code with meaningful variable
> names 
> and a meanigful condition starts to get a bit long:
> 
>     # this line desperately needs to be split over two lines
>     for student in students if mean(student.grade(subject) for
> subject in student.get_subjects()) > 0.8):
>     ...
> 
> When I write list comprehensions with an if condition, probably 90%
> of 
> the time I end up moving the if condition to a second or even third
> line 
> of the comprehension. I expect the same will apply here.
> 
> To save one line for maybe 10% of my for...if constructs, I don't
> think 
> it is worth the bother of adding yet another way to do it.
> 
> 

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KTM6XDMOMQW4W7XRDMG7S65EL34GXAZG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[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 code?

I see no new functionality here. Is the only advantage that you save one 
line and one indent level? Both are cheap.

To be precise, one extra line in something which is already a multiline 
statement is essentially insignificant, and while an extra indent level 
*can* be important, if you have already used so many indents that it 
becomes important, you probably should be refactoring your code.

All I see here is adding to the complexity of the parser and the 
language for no meaningful benefit. Its not even easier to read, it 
crams more on one line which in real code with meaningful variable names 
and a meanigful condition starts to get a bit long:

# this line desperately needs to be split over two lines
for student in students if mean(student.grade(subject) for subject in 
student.get_subjects()) > 0.8):
...

When I write list comprehensions with an if condition, probably 90% of 
the time I end up moving the if condition to a second or even third line 
of the comprehension. I expect the same will apply here.

To save one line for maybe 10% of my for...if constructs, I don't think 
it is worth the bother of adding yet another way to do it.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/II6GPMHWFOM4LHTWV2C7JA4N4HOALW2N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Chris Angelico]

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  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 be aborted, or when something
> > succeeds and there is no need to try alternatives) at various points
> > with `break`.
>    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()
>    except MyBreak:
>    pass
> 
> >>> All this is assuming that you can't refactor it into a function and
> >>> 'return' each time. That's also a viable option, where applicable.
> >> Yes, it is a viable (even preferable) option when applicable.
> >> But there are times when it is not applicable, or is very inconvenient.
> >> E.g. when a long list of local variables have to be turned into long
> >> verbose error-prone and hard-to maintain lists of parameters and return
> >> values (if the code is factored off into a function).
> > Inner functions are spectacular for that :)
> >
> >
> Well, they can do the job.  'spectacular' is not a word I would use:
> (a) you have to define your inner function, then call it:
>  def innerfunc():
>  
>  innerfunc()
>  which obscures the control flow.

If this is something you find yourself doing a lot, it wouldn't be
hard to make a "breakable" decorator:

def breakable(f): return f()

def do_lots_of_work():
x, y, z = 1, 2, "spam"
@breakable
def inner():
if x < y: return
print(z)
...

This doesn't obscure the control flow any more than a 'while' loop, or
any other breakable construct you might come up with. It has a header
that says what it does, and then you have the body, which ends at the
unindent.

> (b) AFAICS If you want to alter variables local to the outer function,
> you have to declare them non-local in the inner function.

Yes, that's true. But that's not very common. Bear in mind that the
inner function can 'return x' to pass a value back, which can easily
be captured when you call it (in the decorator example I gave, it's
automatically captured into the name of the block), and of course you
can mutate any object owned by the outer scope. Chances are you'll
never have more than a small handful of nonlocals in the inner
function.

> (c) AFAIK you can not create identifiers in the inner function which the
> outer function can "see".  Example:
>
>  def f():
>  def innerfunc():
>  foo = 1
>  innerfunc()
>  print(foo)
> f()
>
> print(foo) fails.  You have to create foo in the outer function, then
> declare it non-local:
>
> def f():
>  foo = None
>  def innerfunc():
>  nonlocal foo
>  foo = 1
>  innerfunc()
>  print(foo)
>
> f()
>
> This "works": print(foo) prints 1.

This is also true, but for the use-case you're describing, where you
want to break at arbitrary points, it seems highly likely that you'd
want to initialize it to some default. So in theory, this is a
problem, but in practice, almost never.

> Pretty much as inconvenient as creating parameter and return lists, ISTM.
> No, so far I have seen no improvement on this which I use (including a
> suitable helpful comment, as below) in production code:

Not NEARLY as inconvenient in practice. I don't have absolute proof of
this, but I can assure you that when I need to break out a function in
a language that doesn't support closures (like deferring execution of
part of some code in SourcePawn - the only way is to create a
standalone function, set a timer to call the function at the right
point, and pass it al the arguments), it feels way WAY clunkier than
simply referencing variables. The main reason for this is that it's a
lot more common to *read* variables from outer scopes than to *write*
to them.

>  for _ in '1':   # Execute this 'loop' once only (break once we
> know how to ...)
>  
>

That's also viable, and personally, I'd probably prefer this over
"while True:" and "break" at the end, although I've used both.

There are many ways to do things, and very few design decisions are
fundamentally WRONG. They all have consequences, and you can accept
whichever consequences you choose.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To un

[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops

[Paul Bryan]

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 comprehensions in order to simplify for loop statements:
> 
>  `for .. in .. if ..:`
> 
> E.g.
> 
>  for x in y if x in c:
>  some_op(x)
> 
> which is functionally equivalent as
> 
>  for x in y:
>  if x not in c:
>  continue
>  some_op(x)
> 
> 
> The `for .. in .. if` syntax is a well-known construct from list 
> comprehension syntax [1]. Other alternative ways to do this with list
> comprehension is:
> 
>  for x in (a for a in y if c):
> 
> or
> 
>  it = (a for a in y if c)
>  for x in it:
> 
> Without having examined all use cases, I believe the same syntax
> should 
> be applied this syntax as for asynchronous comprehensions.
> 
> 
> [1] PEP 202 - List Comprehensions
> [2] PEP 530 - Asynchronous Comprehensions
> 
> 
> Best regards,
> Svein Seldal
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7IXPROG2ANAFZTHZC4G3HRVXSKRIPXDL/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JPRJLYUFZOCZAC43CUHMOTZK4W2OCXXQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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 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`.

  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()
  except MyBreak:
  pass


All this is assuming that you can't refactor it into a function and
'return' each time. That's also a viable option, where applicable.

Yes, it is a viable (even preferable) option when applicable.
But there are times when it is not applicable, or is very inconvenient.
E.g. when a long list of local variables have to be turned into long
verbose error-prone and hard-to maintain lists of parameters and return
values (if the code is factored off into a function).

Inner functions are spectacular for that :)



Well, they can do the job.  'spectacular' is not a word I would use:
(a) you have to define your inner function, then call it:
        def innerfunc():
            
        innerfunc()
    which obscures the control flow.
(b) AFAICS If you want to alter variables local to the outer function, 
you have to declare them non-local in the inner function.
(c) AFAIK you can not create identifiers in the inner function which the 
outer function can "see".  Example:


    def f():
    def innerfunc():
    foo = 1
    innerfunc()
    print(foo)
f()

print(foo) fails.  You have to create foo in the outer function, then 
declare it non-local:


def f():
    foo = None
    def innerfunc():
    nonlocal foo
    foo = 1
    innerfunc()
    print(foo)

f()

This "works": print(foo) prints 1.
Pretty much as inconvenient as creating parameter and return lists, ISTM.
No, so far I have seen no improvement on this which I use (including a 
suitable helpful comment, as below) in production code:


    for _ in '1':   # Execute this 'loop' once only (break once we 
know how to ...)

            

Best wishes,
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QLJKQNGFP7NFVYVN46UBY3CT2MML7OKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Syntax proposal of for..in..if in regular for loops

[Svein Seldal]

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.

for x in y if x in c:
some_op(x)

which is functionally equivalent as

for x in y:
if x not in c:
continue
some_op(x)


The `for .. in .. if` syntax is a well-known construct from list 
comprehension syntax [1]. Other alternative ways to do this with list 
comprehension is:


for x in (a for a in y if c):

or

it = (a for a in y if c)
for x in it:

Without having examined all use cases, I believe the same syntax should 
be applied this syntax as for asynchronous comprehensions.



[1] PEP 202 - List Comprehensions
[2] PEP 530 - Asynchronous Comprehensions


Best regards,
Svein Seldal
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7IXPROG2ANAFZTHZC4G3HRVXSKRIPXDL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Chris Angelico]

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 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`.
> >>  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()
> >>  except MyBreak:
> >>  pass
> >>
> > All this is assuming that you can't refactor it into a function and
> > 'return' each time. That's also a viable option, where applicable.
> Yes, it is a viable (even preferable) option when applicable.
> But there are times when it is not applicable, or is very inconvenient.
> E.g. when a long list of local variables have to be turned into long
> verbose error-prone and hard-to maintain lists of parameters and return
> values (if the code is factored off into a function).

Inner functions are spectacular for that :)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QJWNWGK6W2MB6NQO3ZD6GRZLC5J43XC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Greg Ewing]

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 relies on it, for example.

--
Greg

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LECKY3GEIKHX67QPN42UZZOXWG3GAT4V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Steven D'Aprano]

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 StopIteration to end iteration. The older 
sequence protocol uses IndexError for the same purpose.


> As I see it, the original meaning of an exception (in whatever language) 
> is "something unexpected has happened" or "something has gone wrong".

No. An exception is *something EXCEPTIONAL has happened*.

That could be something unexpected, or an error, but it can also be 
something boringly expected and normal, such as KeyError (key not 
found), or StopIteration (finite iterator has reached the end) etc.

Really, pretty much every SpamError exception can be considered a 
non-error, depending on the semantics of how it is being used.

duck.quack  # AttributeError signals an error condition
dog.quack   # AttributeError signals the expected, non-error condition

but this goes double for KeyError, where "missing key" is boringly 
normal.

Using signals for flow control is an old, and fundamental, technique. 
Exceptions are just another kind of signal.

https://ix.cs.uoregon.edu/~norris/cis330/slides/CIS330_Week9.pdf


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/573B6Y66YLDOZIVDUQH3EICVLZHJQQZW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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: raise MyBreak
        do_last_step()
    except MyBreak:
        pass


Why not:

    while True:
        [loop body with ordinary breaks]
        break

It's less to write and almost free of charge*, and it also supports 
redo (continue).




"Almost free" is not free.
One cost is when you forget to add the final `break`.  (I'm sure I've 
done it!)
More important, it obscures the fact that the "loop" is intended to be 
executed only once (particularly if the loop body is long, so that the 
final `break` is a long way from the `while True`).  `while True` 
normally introduces a loop that can be executed multiple times or 
indefinitely.

Best wishes
Rob cliffe___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S3KS7KJIEXJUAVZAUJKCF5XU6QRDONEY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Ben Rudiak-Gould]

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:
> pass
>

Why not:

while True:
[loop body with ordinary breaks]
break

It's less to write and almost free of charge*, and it also supports redo
(continue).

MyBreak has the advantage that you can raise it in nested loops and
subfunctions, although that could be a disadvantage since it makes the
control flow confusing.

This goes for repeat-until also: I always write it while True: ... if cond:
break. I just grepped through some personal Python projects and about 40%
of my while-loop conditions are True.

* The break at the end is free, but Python 3.10.2 inserts a NOP at the
location of the while True, and the peephole optimizers of earlier Python
versions have done other things. It looks like there's been a lot of work
on bytecode efficiency in 3.11, so maybe it will become truly free, but I
haven't checked.

3.11 has range-based exception handling (issue 40222), so the try: approach
is free if you don't raise MyBreak (but expensive if you do).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EBNBHLKGNPGF73QKASXM4JF535AMA2UU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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()
 except MyBreak:
 pass



It doesn't feel right to me to use exceptions purely to direct control 
flow.  YMMV.
As I see it, the original meaning of an exception (in whatever language) 
is "something unexpected has happened" or "something has gone wrong".  
While it is too narrow to insist that they only be used with that 
meaning, this use doesn't feel like a good fit.

Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JUJJ5AI627S5JUUYOS7TQ6BZBTA4IZTZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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 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`.

 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()
 except MyBreak:
 pass


All this is assuming that you can't refactor it into a function and
'return' each time. That's also a viable option, where applicable.

Yes, it is a viable (even preferable) option when applicable.
But there are times when it is not applicable, or is very inconvenient.  
E.g. when a long list of local variables have to be turned into long 
verbose error-prone and hard-to maintain lists of parameters and return 
values (if the code is factored off into a function).

Rob Cliffe


ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GN5MM3CKTMF5B3IGNZFM2BJ6OHNWWY7I/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2I5R6ZNVLEQUAMEWNT4EI4FWLJ4SBCJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Chris Angelico]

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 -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CEI6DUQELTT3IRN6VKKCCPZXBBWXCOSW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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 
block) compare to a len-1 loop?


Om



 On Tue, 01 Mar 2022 10:04:31 -0600 *python-ideas@python.org * 
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 to try alternatives)
at various points with `break`.  Thus avoiding multiple if...then
indentation levels.
Of course it can be spelled as
    for _ in '1':
    for _ in ['once']:
etc. etc., so this is only a cosmetic need.
Best wishes
Rob Cliffe

On 01/03/2022 15:19, Eric Fahlgren wrote:

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/python-ideas@python.org/thread/EDNARFL2RGOE53SLWPTD5ZLJQOYSVDCR



On Tue, Mar 1, 2022 at 7:09 AM mailto:lynneandal...@optusnet.com.au>> wrote:

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 format these messages, I've
used '{' for  line-beak-and-indent, ')' for
line-break-and-dedent, and ';' for
line-break-keeping-same-indent-level.

My initial thoughts are that it would be reasonably easy
to add a 'repeat: ( do thing ) until condition' which
would far better specify intent of the loop (despite the
possibility of break, while-true loops give no indication
that it's not an infinite loop.

And using repeat...until will ensure whoever had to add
the code to the Python interpreter wouldn't have any
clashes with the current while loop.

Thoughts, anyone? Anyone? Bueller? :-)
___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to
python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/

Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/2PM6QEZJAPE3H72GA6TJJIWNBT3Y3WLN/


Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-ideas mailing list --python-ideas@python.org  

To unsubscribe send an email topython-ideas-le...@python.org  

https://mail.python.org/mailman3/lists/python-ideas.python.org/  

Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/BYNJ6C45M2QW6BA7QILGWTYYCCGETKSV/
  

Code of Conduct:http://python.org/psf/codeofconduct/  



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/QAGHJPBP72FBTC2GDGYY435JFUX3EJJF/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MVZW4

[Python-ideas] Re: repeat until

[Chris Angelico]

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 be aborted, or when something
> > succeeds and there is no need to try alternatives) at various points
> > with `break`.
>
> 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()
> except MyBreak:
> pass
>

All this is assuming that you can't refactor it into a function and
'return' each time. That's also a viable option, where applicable.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GN5MM3CKTMF5B3IGNZFM2BJ6OHNWWY7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Steven D'Aprano]

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 to try alternatives) at various points 
> with `break`.

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()
except MyBreak:
pass


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NHEKCV2MDRDKDVVGABCKSD2L4XSD7Y2W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[om]

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 use case: get user to input a number greater than 3.

```
enter_dw = True
while enter_dw or x <= 3:
enter_dw = False
x = int(input("enter a number greater than 3: "))
```


Though the enter_dw variable is a bit clunky.

Tangentially, using this same pattern you could also turn `for x in range(10)` 
into a C-style for loop

```
x = 0
while x < 10:
do_something()
x += 1
```

so you have more control of x inside the loop (ie not just incrementing each 
cycle like the range).


  On Tue, 01 Mar 2022 12:59:26 -0600 Kevin Mills  
wrote 
 > 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-ideas mailing list -- python-ideas@python.org
 > To unsubscribe send an email to python-ideas-le...@python.org
 > https://mail.python.org/mailman3/lists/python-ideas.python.org/
 > Message archived at 
 > https://mail.python.org/archives/list/python-ideas@python.org/message/4BSR3YI7HBD3DOAXQ7GA7XCVJUP7Z4B2/
 > Code of Conduct: http://python.org/psf/codeofconduct/
 > 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6QNARUGFAWOEI7JFBJAMWCGKH4TZQMA7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Kevin Mills]

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-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4BSR3YI7HBD3DOAXQ7GA7XCVJUP7Z4B2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Om Joshi]

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  
python-ideas@python.org  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 to try alternatives) at
various points with `break`.  Thus avoiding multiple if...then
indentation levels.
Of course it can be spelled as
    for _ in '1':
    for _ in ['once']:
etc. etc., so this is only a cosmetic need.
Best wishes
Rob Cliffe

On 01/03/2022 15:19, Eric Fahlgren
  wrote:


  
  
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/python-ideas@python.org/thread/EDNARFL2RGOE53SLWPTD5ZLJQOYSVDCR
  
  
  
On Tue, Mar 1, 2022 at 7:09 AM
  
  wrote:

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 format these messages, I've used '{' for 
  line-beak-and-indent, ')' for line-break-and-dedent, and ';'
  for line-break-keeping-same-indent-level.
  
  My initial thoughts are that it would be reasonably easy to
  add a 'repeat: ( do thing ) until condition' which would far
  better specify intent of the loop (despite the possibility of
  break, while-true loops give no indication that it's not an
  infinite loop.
  
  And using repeat...until will ensure whoever had to add the
  code to the Python interpreter wouldn't have any clashes with
  the current while loop.
  
  Thoughts, anyone? Anyone? Bueller? :-)
  ___
  Python-ideas mailing list -- python-ideas@python.org
  To unsubscribe send an email to python-ideas-le...@python.org
  https://mail.python.org/mailman3/lists/python-ideas.python.org/
  Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2PM6QEZJAPE3H72GA6TJJIWNBT3Y3WLN/
  Code of Conduct: http://python.org/psf/codeofconduct/

  
  
  
  ___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BYNJ6C45M2QW6BA7QILGWTYYCCGETKSV/
Code of Conduct: http://python.org/psf/codeofconduct/



  

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QAGHJPBP72FBTC2GDGYY435JFUX3EJJF/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UMXAO7FFEO72SMT4UKRHPILOYXNX7NRR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Rob Cliffe via Python-ideas]

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...then indentation levels.

Of course it can be spelled as
    for _ in '1':
    for _ in ['once']:
etc. etc., so this is only a cosmetic need.
Best wishes
Rob Cliffe

On 01/03/2022 15:19, Eric Fahlgren wrote:
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/python-ideas@python.org/thread/EDNARFL2RGOE53SLWPTD5ZLJQOYSVDCR

On Tue, Mar 1, 2022 at 7:09 AM  wrote:

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 format these messages, I've used '{' for
line-beak-and-indent, ')' for line-break-and-dedent, and ';' for
line-break-keeping-same-indent-level.

My initial thoughts are that it would be reasonably easy to add a
'repeat: ( do thing ) until condition' which would far better
specify intent of the loop (despite the possibility of break,
while-true loops give no indication that it's not an infinite loop.

And using repeat...until will ensure whoever had to add the code
to the Python interpreter wouldn't have any clashes with the
current while loop.

Thoughts, anyone? Anyone? Bueller? :-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/2PM6QEZJAPE3H72GA6TJJIWNBT3Y3WLN/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/BYNJ6C45M2QW6BA7QILGWTYYCCGETKSV/
Code of Conduct:http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QAGHJPBP72FBTC2GDGYY435JFUX3EJJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: repeat until

[Eric Fahlgren]

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/python-ideas@python.org/thread/EDNARFL2RGOE53SLWPTD5ZLJQOYSVDCR

On Tue, Mar 1, 2022 at 7:09 AM  wrote:

> 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 format
> these messages, I've used '{' for  line-beak-and-indent, ')' for
> line-break-and-dedent, and ';' for line-break-keeping-same-indent-level.
>
> My initial thoughts are that it would be reasonably easy to add a 'repeat:
> ( do thing ) until condition' which would far better specify intent of the
> loop (despite the possibility of break, while-true loops give no indication
> that it's not an infinite loop.
>
> And using repeat...until will ensure whoever had to add the code to the
> Python interpreter wouldn't have any clashes with the current while loop.
>
> Thoughts, anyone? Anyone? Bueller? :-)
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/2PM6QEZJAPE3H72GA6TJJIWNBT3Y3WLN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BYNJ6C45M2QW6BA7QILGWTYYCCGETKSV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] repeat until

[lynneandallan]

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 format 
these messages, I've used '{' for  line-beak-and-indent, ')' for 
line-break-and-dedent, and ';' for line-break-keeping-same-indent-level.

My initial thoughts are that it would be reasonably easy to add a 'repeat: ( do 
thing ) until condition' which would far better specify intent of the loop 
(despite the possibility of break, while-true loops give no indication that 
it's not an infinite loop.

And using repeat...until will ensure whoever had to add the code to the Python 
interpreter wouldn't have any clashes with the current while loop.

Thoughts, anyone? Anyone? Bueller? :-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2PM6QEZJAPE3H72GA6TJJIWNBT3Y3WLN/
Code of Conduct: http://python.org/psf/codeofconduct/