[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Stephen J. Turnbull]

Rob Cliffe writes:

 > Did you see Guido's post when I raised a similar object to detecting 
 > "zero iterations", where it would be unacceptable to slow down all 
 > for-loops, so they would have to be compiled differently?

Yes.  My confusion (as you'll see elsewhere) was about the AST, not
the parser.

 > > Second, generally Python tries to avoid overloading keywords with
 > > multiple semantics.  The potential for confusion and misunderstanding
 > > of "except" (which I've suggested myself and now dislike) is pretty
 > > large I think.

 > IMO this is a bit disingenuous:

I'm not trying to mislead anybody, or try to imply there aren't cases
where keywords have been repurposed.

 >   "as" can be used with "import" and with context managers with 
 > quite different semantics.

I would disagree that the semantics are different.  Context managers
and imports have quite different semantics, but in both cases the "as"
clause has name binding semantics, while the object bound is
determined by the statement, not by the "as" clause.

 >      "del" can be used to remove a variable binding, a sequence element, 
 > a sequence slice or a dictionary key.

The connection is more tenuous, but in each case an object loses a
reference.  I see your point of view, especially since the semantics
of del on sequence elements and slices affects the "names" of other
sequence elements, but I think the "reference destruction" semantics
are "sufficiently" similar across the different uses of "del".

 >      "not" can be used as Boolean negation or in the compound operator 
 > "not in".

Which is a negation.  I don't see how anybody reading that could
mistake the meaning.

 > Whereas the new use of "except" that Matthew is proposing is very
 > similar to its existing use (certainly conceptually, if not in the
 > implementation details).

As a restricted goto, that is true.  In fact, it's so similar that we
may as well use the original!  Is one level of indentation really
worth it?

What I see as different is that Matthew's proposal is for a purpose
that is explicitly local to the loop statement, where except is
explicitly nonlocal.  Another way to put it is in this thread "except"
is proposed as marking a goto target, where in a try "except" is
almost a "come from" (although not with full INTERCAL compatility).

I also wonder about try ... excepts nested in a for loop with
excepts.  That's probably no harder to deal with than nested loops
with breaks at different levels (but that can be a bit confusing).

 > (To be clear: although I'm defending Matthew's proposal here, my 
 > preferred option is still some new syntax.)

"try" is enough to implement any of the use cases in the relatively
rare cases it's needed.

On the plus side, a "try" and its except clauses require a bit of code
to set up.  I don't know whether that's a major consideration, but one
advantage of a new implementation for the purpose of implementing
"labelled breaks" would be to have a lighter implementation.  Whether
it's worth it is above my pay grade.

___
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/DC77MEHTY4NMLUSIRS7JFKQA4FF6UNHX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Stephen J. Turnbull]

Guido van Rossum writes:

 > Maybe you’re thinking of a “one-pass” compiler, like the original Pascal
 > compiler, that generates code during parsing.

Not really.  The "after" phrasing comes from the parsing part which
does move through the source pretty much linearly in both the
traditional and PEG parsers (as far as I understand the latter).

What I really meant with respect to the code generation was what you
describe as "going 'up'" with respect to the AST.  Evidently I got
that wrong.

I have a somewhat nebulous understanding of which way is "up", I
guess. :-)  I need to go back to school on compiler tech.
___
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/Y5BJRTXITUITRDMWWHXDFRE2I65EZMC3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Guido van Rossum]

On Thu, Aug 6, 2020 at 01:00 Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> However, we would probably not want to burden all loops with the
> exception-handling machinery, so the compiler would have to do some
> hacky backtracking (I doubt that the arbitrary lookahead needed to
> handle "maybe we got some except clauses coming?" during parsing would
> be acceptable) and fill that in *after* recognizing that there are
> except clauses in this for statement.


Maybe you’re thinking of a “one-pass” compiler, like the original Pascal
compiler, that generates code during parsing. That’s not how modern
compilers work anymore. :-) The parser builds an AST, and the code
generator uses the whole AST as input. It would not be “hacky” for the
compiler to generate different code for the first half of a compound
statement depending on how it ends.

(However, it *would* be hacky to vary based on whether a statement was
followed by a certain other statement, as that would require going “up” in
the AST.)

—Guido
-- 
--Guido (mobile)
___
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/U35XAOQ4VWTOR7ZW3ODD2XKLINKXTSYV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

On 06/08/2020 08:57, Stephen J. Turnbull wrote:

Mathew Elman writes:

  > Being able to break multiple loops and having "labelled" breaks
  > would be achievable using `except`, i.e. adding `except` to the
  > loop statements before `else` like this:

This would certainly be consistent with the existing use of the except
keyword, unlike the proposal to have it take both exceptions (in 'try'
statements) and break labels (in 'for' and 'while' statements).

However, we would probably not want to burden all loops with the
exception-handling machinery, so the compiler would have to do some
hacky backtracking (I doubt that the arbitrary lookahead needed to
handle "maybe we got some except clauses coming?" during parsing would
be acceptable) and fill that in *after* recognizing that there are
except clauses in this for statement.


Did you see Guido's post when I raised a similar object to detecting 
"zero iterations", where it would be unacceptable to slow down all 
for-loops, so they would have to be compiled differently?

I wrote (in ignorance:-)):

   So: You're asking that the bytecode generated for the for-loop depends
   on something that happens (or not) after the end of the for-loop body
   (which could be arbitrarily long).

   I speak from ignorance, but I suspect that even with the new parser,
   which I am reliably informed can make the tea and implement world
   peace,
   that would be asking a lot.

Guido replied:
Rest assured this is not a problem. In any case it’s the compiler, not 
the parser, that generates the bytecode, from the AST. The compiler 
always has the full AST available before it is asked to generate any 
bytecode. The new parser just allows more flexible syntactic constructs, 
esp. “soft keywords”.




Second, generally Python tries to avoid overloading keywords with
multiple semantics.  The potential for confusion and misunderstanding
of "except" (which I've suggested myself and now dislike) is pretty
large I think.

IMO this is a bit disingenuous:
 "as" can be used with "import" and with context managers with 
quite different semantics.
    "del" can be used to remove a variable binding, a sequence element, 
a sequence slice or a dictionary key.
    "not" can be used as Boolean negation or in the compound operator 
"not in".
Whereas the new use of "except" that Matthew is proposing is very 
similar to its existing use (certainly conceptually, if not in the 
implementation details).


It might be possible to save that level of indentation with this
syntax:

 try for elem in iterable:
 ...
 if should_break(elem):
 raise SomeException
 except SomeException as e:
 handle_break_behaviour(e)
 else:
 print("Did not break")

(and I suppose you could do the same for any control flow statement,
although I'm not sure offhand that the various keywords are 100%
disjoint -- that would need to be checked).  But I don't think it's
worth it.  I don't see enough benefits from this mixing of try and for
to make it worth the complexity.

  > I (and others) have suggested this before and no one has said it's a
  > *bad *option,

It is, though, for the reasons above as well as the reasons Rob gives
in his parallel followup.

Steve
(To be clear: although I'm defending Matthew's proposal here, my 
preferred option is still some new syntax.)

___
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/OVRYSB4WRAYWSD2UGUS5MZHQ2PCZLUJR/
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/AGHWSJ7R3OU5ZFHBOC65MDLYSMEUVVLD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Mathew Elman]

Thank you both for the feedback.

Some pros and cons that occur to me (I may be biased, YMMV):
> Pros:
> (1) It can cleanly separate the handling of break-type exceptions and
> other exceptions, if needed.
> (2) It actually clarifies what the dreaded "else" means!
> (3) it allows you to group your "break" cases using exception
> subclasses (although this is probably OTT for most use cases).
> Cons:
> (4) It's more work.  You have to decide what exceptions to use and
> (most likely) create them.
>
(5) It adds the runtime overhead of setting up the "try" and possibly
> raising the exception.
> (6) Putting (implicitly) try...except around a possibly long for-suite
> feels bad somehow, even though it wouldn't catch other unwanted
> exceptions.
> (7) It does not catch the "zero iterations" case.
>

It is possible that 4 and 7 may be fixed by adding 2 new Exception
subclasses, e.g. `BreakException`, which would "replace" break although
using break would still be possible, and `NoIterationException` (though
this may not be the cleanest approach). The question then becomes what to
do with these when there is no `except`. At the sacrifice of automatically
breaking out of multiple loops, they could be silently ignored unless
caught explicitly?

I do not know well enough how the python interpreter sets up `try-except`
blocks to realistically respond to 5 and 6 but I can indeed see these being
sticking points.

On Thu, 6 Aug 2020 at 08:57, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Mathew Elman writes:
>
>  > Being able to break multiple loops and having "labelled" breaks
>  > would be achievable using `except`, i.e. adding `except` to the
>  > loop statements before `else` like this:
>
> This would certainly be consistent with the existing use of the except
> keyword, unlike the proposal to have it take both exceptions (in 'try'
> statements) and break labels (in 'for' and 'while' statements).
>
> However, we would probably not want to burden all loops with the
> exception-handling machinery, so the compiler would have to do some
> hacky backtracking (I doubt that the arbitrary lookahead needed to
> handle "maybe we got some except clauses coming?" during parsing would
> be acceptable) and fill that in *after* recognizing that there are
> except clauses in this for statement.
>

Would it be so bad to simply wrap for loops with except clauses
automatically that can be clobbered or not?
e.g.

> for x in iterable:
> ...
>
really does something like this

> try:
>
for x in iterable:
> ...
> except Exception:
> raise
>

Meaning that it doesn't need to wait to see if it does and backtrace but
can just trust that there will be the default reraise? Apologies if this is
a stupid question.

Second, generally Python tries to avoid overloading keywords with
> multiple semantics.  The potential for confusion and misunderstanding
> of "except" (which I've suggested myself and now dislike) is pretty
> large I think.
>

I am not sure I follow you here since the `except` is being used in the
same way as in `try...except` so I wouldn't expect a high potential for
confusion, although I suppose that is, ironically, the same line of
thinking as with `for...else`.


> It might be possible to save that level of indentation with this
> syntax:
>
> try for elem in iterable:
> ...
> if should_break(elem):
> raise SomeException
> except SomeException as e:
> handle_break_behaviour(e)
> else:
> print("Did not break")
>
> (and I suppose you could do the same for any control flow statement,
> although I'm not sure offhand that the various keywords are 100%
> disjoint -- that would need to be checked).  But I don't think it's
> worth it.  I don't see enough benefits from this mixing of try and for
> to make it worth the complexity.
>

I agree that this seems to add some complexity but I actually like this a
lot. It would surely also address the issue of the parser knowing it should
be looking for exceptions or not?


>  > I (and others) have suggested this before and no one has said it's a
>  > *bad *option,
>
> It is, though, for the reasons above as well as the reasons Rob gives
> in his parallel followup.
>

Thank you, I appreciate it at least being addressed!

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses.

References to the 
"Ocado Group" are to Ocado Group plc (registered in England and Wales with 
number 7098618) and its subsidiary undertakings (as that expression is 
defined in the Companies Act 2006) from time to time. The registered 

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Stephen J. Turnbull]

Mathew Elman writes:

 > Being able to break multiple loops and having "labelled" breaks
 > would be achievable using `except`, i.e. adding `except` to the
 > loop statements before `else` like this:

This would certainly be consistent with the existing use of the except
keyword, unlike the proposal to have it take both exceptions (in 'try'
statements) and break labels (in 'for' and 'while' statements).

However, we would probably not want to burden all loops with the
exception-handling machinery, so the compiler would have to do some
hacky backtracking (I doubt that the arbitrary lookahead needed to
handle "maybe we got some except clauses coming?" during parsing would
be acceptable) and fill that in *after* recognizing that there are
except clauses in this for statement.

Second, generally Python tries to avoid overloading keywords with
multiple semantics.  The potential for confusion and misunderstanding
of "except" (which I've suggested myself and now dislike) is pretty
large I think.

It might be possible to save that level of indentation with this
syntax:

try for elem in iterable:
...
if should_break(elem):
raise SomeException
except SomeException as e:
handle_break_behaviour(e)
else:
print("Did not break")

(and I suppose you could do the same for any control flow statement,
although I'm not sure offhand that the various keywords are 100%
disjoint -- that would need to be checked).  But I don't think it's
worth it.  I don't see enough benefits from this mixing of try and for
to make it worth the complexity.

 > I (and others) have suggested this before and no one has said it's a
 > *bad *option,

It is, though, for the reasons above as well as the reasons Rob gives
in his parallel followup.

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/OVRYSB4WRAYWSD2UGUS5MZHQ2PCZLUJR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

On 05/08/2020 15:29, Mathew Elman wrote:
Being able to break multiple loops and having "labelled" breaks would 
be achievable using `except`, i.e. adding `except` to the loop 
statements before `else` like this:


for elem in iterable:
    ...
    if should_break(elem):
    raise SomeException
except SomeException as e:
    handle_break_behaviour(e)
else:
    print("Did not break")


would be sugar for:

try:
    for elem in iterable:
    ...
    if should_break(elem):
        raise SomeException
except SomeException as e:
    handle_break_behaviour(e)
else:
    print("Did not break")

I (and others) have suggested this before and no one has said it's a 
/bad /option, it's just been ignored, despite seeming to be an 
intuitive way to accomplish `else` clarity, "labelled" breaks and 
breaking from multiple loops. Is there a reason that this suggestion 
is worse / no better than adding special break syntax?



It's certainly a reasonable option.  Indeed, I would consider using the 
second (currently legal) version in my own code if it seemed appropriate.

Some pros and cons that occur to me (I may be biased, YMMV):
Pros:
    (1) It can cleanly separate the handling of break-type exceptions 
and other exceptions, if needed.

    (2) It actually clarifies what the dreaded "else" means!
    (3) it allows you to group your "break" cases using exception 
subclasses (although this is probably OTT for most use cases).

Cons:
    (4) It's more work.  You have to decide what exceptions to use and 
(most likely) create them.
    (5) It adds the runtime overhead of setting up the "try" and 
possibly raising the exception.
    (6) Putting (implicitly) try...except around a possibly long 
for-suite feels bad somehow, even though it wouldn't catch other 
unwanted exceptions.

    (7) It does not catch the "zero iterations" case.

If, contra your suggestion, special syntax were to be added, it could 
use "except" instead of "if ... elif".

For example (this is just doodling, it's not a fully thought-out proposal):

    for x in range(10):
        ...
        if :
            break "oops" # under the hood this is a compiled jump, not 
the raising of an exception

        if :
            break 42
    except "oops":
        
    except 42:
        
    except break:
        # catches all "break"s not already explicitly caught
        pass
    else:
        print("Did not break")

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/GMFVTUN6EYW5EODMGVWZEBBXCEACXG3G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Mathew Elman]

Being able to break multiple loops and having "labelled" breaks would be
achievable using `except`, i.e. adding `except` to the loop statements
before `else` like this:

for elem in iterable:
> ...
> if should_break(elem):
> raise SomeException
> except SomeException as e:
> handle_break_behaviour(e)
> else:
> print("Did not break")
>

would be sugar for:

try:
> for elem in iterable:
> ...
> if should_break(elem):
> raise SomeException
> except SomeException as e:
> handle_break_behaviour(e)
> else:
> print("Did not break")
>

I (and others) have suggested this before and no one has said it's a
*bad *option,
it's just been ignored, despite seeming to be an intuitive way to
accomplish `else` clarity, "labelled" breaks and breaking from multiple
loops. Is there a reason that this suggestion is worse / no better than
adding special break syntax?

As for an example for labelled breaks how about something of the form:

def insert_ordered_no_duplicates(duplicate_free_list, item):
> for i, elem in enumerate(duplicate_free_list):
> if elem == item:
> break already_present
> if elem > item:
> break location_found
> case already_present:
> return duplicate_free_list
> case location_found:
> new_list = duplicate_free_list[:]
> new_list.insert(i, item)
> return new_list
> new_list = duplicate_free_list[:]
> new_list.append(item)
> return new_list
>

which you can conceivably have a nested case where you don't want to let
duplicate inserts even be attempted like this:

def insert_many_ordered_strictly_no_duplicates(dup_free_list, items):
> new_list = dup_free_list[:]
> for item in items:
> for i, elem in new_list:
> if elem == item:
> break already_present
> if elem > item:
> break location_found
> case already_present:
> break duplicates_attempted
> case location_found:
> new_list.insert(i, item)
> else:
> new_list.append(item)
> case duplicates_attempted:
> return dup_free_list[:]
> return new_list
>


On Wed, 5 Aug 2020 at 13:40, Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> I note that both of these examples could be handled by having a way to
> break out of 2 loops at a time.
> Rob
>
> On 29/07/2020 12:33, Jonathan Fine wrote:
>
> Thank you all, particularly Guido, for your contributions. Having some
> examples will help support the exploration of this idea.
>
> Here's a baby example - searching in a nested loop. Suppose we're looking
> for the word 'apple' in a collection of books. Once we've found it, we stop.
>
> for book in books:
> for page in book:
> if 'apple' in page:
> break
> if break:
> break
>
> However, suppose we say that we only look at the first 5000 or so words in
> each book. (We suppose a page is a list of words.)
>
> This leads to the following code.
>
> for book in books:
> word_count = 0
> for page in book:
> word_count += len(page)
> if word in page:
> break
> if word_count >= 5000:
> break found
> if break found:
> break
>
> At this time, I'd like us to focus on examples of existing code, and
> semantics that might be helpful. I think once we have this, the discussion
> of syntax will be easier.
>
> By the way, the word_count example is as I typed it, but it has a typo.
> Did you spot it when you read it? (I only noticed it when re-reading my
> message.)
>
> Finally, thank you for your contributions. More examples please.
>
> --
> Jonathan
>
>
>
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to 
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/
> 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/YV4V2FYLT5SNWOCH7TZNXYCQRAQZ6R33/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all 

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

I note that both of these examples could be handled by having a way to 
break out of 2 loops at a time.

Rob

On 29/07/2020 12:33, Jonathan Fine wrote:
Thank you all, particularly Guido, for your contributions. Having some 
examples will help support the exploration of this idea.


Here's a baby example - searching in a nested loop. Suppose we're 
looking for the word 'apple' in a collection of books. Once we've 
found it, we stop.


    for book in books:
        for page in book:
            if 'apple' in page:
                break
        if break:
            break

However, suppose we say that we only look at the first 5000 or so 
words in each book. (We suppose a page is a list of words.)


This leads to the following code.

    for book in books:
        word_count = 0
        for page in book:
            word_count += len(page)
            if word in page:
                break
            if word_count >= 5000:
                break found
        if break found:
            break

At this time, I'd like us to focus on examples of existing code, and 
semantics that might be helpful. I think once we have this, the 
discussion of syntax will be easier.


By the way, the word_count example is as I typed it, but it has a 
typo. Did you spot it when you read it? (I only noticed it when 
re-reading my message.)


Finally, thank you for your contributions. More examples please.

--
Jonathan





___
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/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/
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/YV4V2FYLT5SNWOCH7TZNXYCQRAQZ6R33/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

On 29/07/2020 14:51, Ethan Furman wrote:

On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote:

A possible, unrelated, future language extension is to allow breaking 
out of more than one loop at a time.


I would think that

    break 

would handle that situation.

--
~Ethan~
Maybe.  But note that you're extending Jonathan's proposal by allowing 
the the label to follow an enclosing loop, not the inner loop (at least 
he certainly didn't say explicitly that he was proposing that).
Also, you have to create the label, even if you don't want to do 
anything when you get there other than 'pass', which is a bit inelegant.

Rob

___
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/LEBAC5QKDXVCBZJ5NUXTSLFBCW2TW42L/

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/5VKZJA5RTFS7ONNNLNYLVSMSPBEELLIS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Jonathan Fine]

Guido wrote:

I honestly and strongly believe that we should do nothing here. Python
> thrives because it is relatively simple. Adding new syntax to deal with
> looping special cases makes it less simple, and encourages a bad coding
> style (nested loops, multiple breaks...).
>

 I agree with about 80% of this statement. In particular I believe strongly
that we should do nothing here, without strong evidence that the change
will bring at least significant benefit to some users, and no or very
little harm to the rest.

I also believe that meeting that criteria is only the first step. It is
quite possible for a reasonable request for change to be reasonably refused.

Again, I believe that one reason why Python thrives is that it is
relatively simple for novices. Another reason is that it provides
facilities such as __dunder__ methods and metaclasses, so that experts can
do advanced things. List comprehensions perhaps lie somewhere in between.

>From a syntactic point of view, I think it important that we do what we can
to avoid novices accidentally encountering an advanced feature. Here's an
example.  PEP 622 -- Structural Pattern Matching suggests introducing a
language feature that, I think, most novices will find hard to understand
properly. But it seems that experts will like it's power and simplicity,
for doing some advanced things.

PEP 622 introduces new keywords 'match' and 'case'. The new keywords make
it easy for us to warn novices not to use it (and we don't put it in the
beginners tutorial). Here's the example from the PEP.

def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")

Some conditions necessary for "break to a label" to be accepted are strong
use cases, and a syntax that keeps the construction out of the hands of the
novices. These conditions are not sufficient.

I intend to keep my eyes open, as I go about my daily activities, of strong
use cases. If I don't see any, then most likely you won't hear anything
more from me on this suggestion.
-- 
Jonathan
___
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/ES2B2AX2KCES3PCTZRFJCZA7AKNUXOVF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[2QdxY4RzWzUUiLuE]

On 2020-07-29 at 07:09:05 -0700,
Guido van Rossum  wrote:

> I honestly and strongly believe that we should do nothing here. Python
> thrives because it is relatively simple. Adding new syntax to deal
> with looping special cases makes it less simple, and encourages a bad
> coding style (nested loops, multiple breaks...).

I was about to go off on another Get Off My Lawn rant, so thank you for
putting this so succintly and so politely.  :-)

If I end up with more than one flag controlling my search loop, then
it's time to break (pun intended) the logic into smaller/simpler pieces
rather than to look for a more complicated language construct.
___
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/V66EY5LEXXTBVYB55NQJXSQNTXFXBVC5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Stephen J. Turnbull]

Jonathan Fine writes:

 > Here's a baby example - searching in a nested loop. Suppose we're
 > looking for the word 'apple' in a collection of books. Once we've
 > found it, we stop.

While I was writing a reply, several people replied with very similar
comments, so I won't repeat them.  But these two examples are so
obnoxious I had to post them:

>>> for page in (page for book in books for page in book if 'a' in page):
...  break
... 
>>> page
'abc'
>>> [page for book in books for page in book if 'a' in page][0]
'abc'
>>> 
___
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/UC5DV2KLXZTRXYBRCAWB7PFODBVNIZDK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Guido van Rossum]

On Wed, Jul 29, 2020 at 07:01 Mathew Elman  wrote:

>
>
> On Wed, 29 Jul 2020 at 14:42, Guido van Rossum  wrote:
>
>> On Wed, Jul 29, 2020 at 02:51 Mathew Elman 
>> wrote:
>>
>>>
>>> .
>>>
 If it *is* useful, it occurs to me that (1) this looks a lot like the
 try ... except ... pattern, and (2) breaks are generally perceived as
 exceptional exits from a loop.  Instead of "if break [LABEL]", "except
 [LABEL]" might work, although the semantic difference between labels
 and exceptions might get a ton of pushback.
>>>
>>> ...

>>> Steve

>>>
>>> In the related thread I suggested using `except`, but it was largely
>>> ignored.
>>>
>>>
>>> *If* you want tou propose clearer syntax for this, please extend the
 loop syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than
 ‘if [not] break’.

>>>
 —Guido

>>>
>>> So I understand, does this mean that any extended syntax for this should
>>> be *totally* new and not draw on existing constructs such as
>>> `try-except` or `if-else`?
>>> Or just that the additional clarity should come from  extending the loop
>>> rather than the implicit `if`?
>>>
>>
>> Actually, given that ‘else:’ already confuses people I very much doubt
>> that any other new construct will be acceptable. It is totally five not to
>> “solve” this problem at all — all use cases can be done by adding flag
>> variables explicitly manipulated by the user’s code.
>>
> I understand that the "problem" with `else` is aesthetic, though one could
> debate the importance of such a problem.
>
> What I mean to ask is, for example,  would having `for-except-else`
> (analogous to `try-except-else`) be an acceptable extension of "the loop
> syntax, not the ‘if’ syntax"?
>

I honestly and strongly believe that we should do nothing here. Python
thrives because it is relatively simple. Adding new syntax to deal with
looping special cases makes it less simple, and encourages a bad coding
style (nested loops, multiple breaks...).


>
>
>>> Mathew
>>>
>>>
>>> Notice:
>>> This email is confidential and may contain copyright material of members
>>> of the Ocado Group. Opinions and views expressed in this message may not
>>> necessarily reflect the opinions and views of the members of the Ocado
>>> Group.
>>>
>>> If you are not the intended recipient, please notify us immediately and
>>> delete all copies of this message. Please note that it is your
>>> responsibility to scan this message for viruses.
>>>
>>> References to the "Ocado Group" are to Ocado Group plc (registered in
>>> England and Wales with number 7098618) and its subsidiary undertakings (as
>>> that expression is defined in the Companies Act 2006) from time to time.
>>> The registered office of Ocado Group plc is Buildings One & Two, Trident
>>> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
>>> ___
>>> 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> --
>> --Guido (mobile)
>>
>
> Notice:
> This email is confidential and may contain copyright material of members
> of the Ocado Group. Opinions and views expressed in this message may not
> necessarily reflect the opinions and views of the members of the Ocado
> Group.
>
> If you are not the intended recipient, please notify us immediately and
> delete all copies of this message. Please note that it is your
> responsibility to scan this message for viruses.
>
> References to the "Ocado Group" are to Ocado Group plc (registered in
> England and Wales with number 7098618) and its subsidiary undertakings (as
> that expression is defined in the Companies Act 2006) from time to time.
> The registered office of Ocado Group plc is Buildings One & Two, Trident
> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
> ___
> 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/YTC6Z4DHUOXSKS7L6MM4HQ4WSZAGVSET/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/A6DGYUOEKUYNT42IOLPJUGT4Z6PZADW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Mathew Elman]

On Wed, 29 Jul 2020 at 14:42, Guido van Rossum  wrote:

> On Wed, Jul 29, 2020 at 02:51 Mathew Elman  wrote:
>
>>
>> .
>>
>>> If it *is* useful, it occurs to me that (1) this looks a lot like the
>>> try ... except ... pattern, and (2) breaks are generally perceived as
>>> exceptional exits from a loop.  Instead of "if break [LABEL]", "except
>>> [LABEL]" might work, although the semantic difference between labels
>>> and exceptions might get a ton of pushback.
>>
>> ...
>>>
>> Steve
>>>
>>
>> In the related thread I suggested using `except`, but it was largely
>> ignored.
>>
>>
>> *If* you want tou propose clearer syntax for this, please extend the loop
>>> syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if
>>> [not] break’.
>>>
>>
>>> —Guido
>>>
>>
>> So I understand, does this mean that any extended syntax for this should
>> be *totally* new and not draw on existing constructs such as
>> `try-except` or `if-else`?
>> Or just that the additional clarity should come from  extending the loop
>> rather than the implicit `if`?
>>
>
> Actually, given that ‘else:’ already confuses people I very much doubt
> that any other new construct will be acceptable. It is totally five not to
> “solve” this problem at all — all use cases can be done by adding flag
> variables explicitly manipulated by the user’s code.
>
I understand that the "problem" with `else` is aesthetic, though one could
debate the importance of such a problem.

What I mean to ask is, for example,  would having `for-except-else`
(analogous to `try-except-else`) be an acceptable extension of "the loop
syntax, not the ‘if’ syntax"?


>> Mathew
>>
>>
>> Notice:
>> This email is confidential and may contain copyright material of members
>> of the Ocado Group. Opinions and views expressed in this message may not
>> necessarily reflect the opinions and views of the members of the Ocado
>> Group.
>>
>> If you are not the intended recipient, please notify us immediately and
>> delete all copies of this message. Please note that it is your
>> responsibility to scan this message for viruses.
>>
>> References to the "Ocado Group" are to Ocado Group plc (registered in
>> England and Wales with number 7098618) and its subsidiary undertakings (as
>> that expression is defined in the Companies Act 2006) from time to time.
>> The registered office of Ocado Group plc is Buildings One & Two, Trident
>> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
>> ___
>> 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> --Guido (mobile)
>

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses.

References to the 
"Ocado Group" are to Ocado Group plc (registered in England and Wales with 
number 7098618) and its subsidiary undertakings (as that expression is 
defined in the Companies Act 2006) from time to time. The registered office 
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, 
Hatfield, Hertfordshire, AL10 9UL.
___
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/YTC6Z4DHUOXSKS7L6MM4HQ4WSZAGVSET/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Ethan Furman]

On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote:

A possible, unrelated, future language extension is to allow breaking 
out of more than one loop at a time.


I would think that

break 

would handle that situation.

--
~Ethan~
___
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/LEBAC5QKDXVCBZJ5NUXTSLFBCW2TW42L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Dominik Vilsmeier]

On 29.07.20 13:33, Jonathan Fine wrote:


Thank you all, particularly Guido, for your contributions. Having some
examples will help support the exploration of this idea.

Here's a baby example - searching in a nested loop. Suppose we're
looking for the word 'apple' in a collection of books. Once we've
found it, we stop.

    for book in books:
        for page in book:
            if 'apple' in page:
                break
        if break:
            break


This can be realized already with `else: continue`:

    for book in books:
        for page in book:
            if 'apple' in page:
                break
        else:
            continue
        break

However it looks more like this should be a function and just return
when there is a match:

    for book in books:
        for page in book:
            if 'apple' in page:
                return True

Or flatten the loop with itertools:

    for page in it.chain.from_iterable(books):
        if 'apple' in page:
            break

This can also be combined with functions `any` or `next` to check if
there's a match or to get the actual page.



However, suppose we say that we only look at the first 5000 or so
words in each book. (We suppose a page is a list of words.)

This leads to the following code.

    for book in books:
        word_count = 0
        for page in book:
            word_count += len(page)
            if word in page:
                break
            if word_count >= 5000:
                break found
        if break found:
            break


This also could be a function that just returns on a match. Or you could
use `itertools.islice` to limit the number of words. I don't see a
reason for double break here.



At this time, I'd like us to focus on examples of existing code, and
semantics that might be helpful. I think once we have this, the
discussion of syntax will be easier.

By the way, the word_count example is as I typed it, but it has a
typo. Did you spot it when you read it? (I only noticed it when
re-reading my message.)

Finally, thank you for your contributions. More examples please.


I think the need for two (or more) distinct `break` reasons or the same
`break` reason at multiple different locations in a loop is pretty rare.
Are there any counter examples? Otherwise such cases can be handled
already today and there's no need for additional syntax (apart from the
"else" ambiguity).
___
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/5OGVHMKXR5K5FACDTKCO2KHTOPYVF66I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Guido van Rossum]

On Wed, Jul 29, 2020 at 02:51 Mathew Elman  wrote:

>
> .
>
>> If it *is* useful, it occurs to me that (1) this looks a lot like the
>> try ... except ... pattern, and (2) breaks are generally perceived as
>> exceptional exits from a loop.  Instead of "if break [LABEL]", "except
>> [LABEL]" might work, although the semantic difference between labels
>> and exceptions might get a ton of pushback.
>
> ...
>>
> Steve
>>
>
> In the related thread I suggested using `except`, but it was largely
> ignored.
>
>
> *If* you want tou propose clearer syntax for this, please extend the loop
>> syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if
>> [not] break’.
>>
>
>> —Guido
>>
>
> So I understand, does this mean that any extended syntax for this should
> be *totally* new and not draw on existing constructs such as `try-except`
> or `if-else`?
> Or just that the additional clarity should come from  extending the loop
> rather than the implicit `if`?
>

Actually, given that ‘else:’ already confuses people I very much doubt that
any other new construct will be acceptable. It is totally five not to
“solve” this problem at all — all use cases can be done by adding flag
variables explicitly manipulated by the user’s code.

>
> Mathew
>
>
> Notice:
> This email is confidential and may contain copyright material of members
> of the Ocado Group. Opinions and views expressed in this message may not
> necessarily reflect the opinions and views of the members of the Ocado
> Group.
>
> If you are not the intended recipient, please notify us immediately and
> delete all copies of this message. Please note that it is your
> responsibility to scan this message for viruses.
>
> References to the "Ocado Group" are to Ocado Group plc (registered in
> England and Wales with number 7098618) and its subsidiary undertakings (as
> that expression is defined in the Companies Act 2006) from time to time.
> The registered office of Ocado Group plc is Buildings One & Two, Trident
> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
> ___
> 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/Y7PMBCC7EE7IWEFXSJN4ZNKFT3DUMSS4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Jonathan Fine]

Thank you all, particularly Guido, for your contributions. Having some
examples will help support the exploration of this idea.

Here's a baby example - searching in a nested loop. Suppose we're looking
for the word 'apple' in a collection of books. Once we've found it, we stop.

for book in books:
for page in book:
if 'apple' in page:
break
if break:
break

However, suppose we say that we only look at the first 5000 or so words in
each book. (We suppose a page is a list of words.)

This leads to the following code.

for book in books:
word_count = 0
for page in book:
word_count += len(page)
if word in page:
break
if word_count >= 5000:
break found
if break found:
break

At this time, I'd like us to focus on examples of existing code, and
semantics that might be helpful. I think once we have this, the discussion
of syntax will be easier.

By the way, the word_count example is as I typed it, but it has a typo. Did
you spot it when you read it? (I only noticed it when re-reading my
message.)

Finally, thank you for your contributions. More examples please.

-- 
Jonathan
___
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/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Mathew Elman]

.

> If it *is* useful, it occurs to me that (1) this looks a lot like the
> try ... except ... pattern, and (2) breaks are generally perceived as
> exceptional exits from a loop.  Instead of "if break [LABEL]", "except
> [LABEL]" might work, although the semantic difference between labels
> and exceptions might get a ton of pushback.

...
>
Steve
>

In the related thread I suggested using `except`, but it was largely
ignored.


*If* you want tou propose clearer syntax for this, please extend the loop
> syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if
> [not] break’.
>

> —Guido
>

So I understand, does this mean that any extended syntax for this should be
*totally* new and not draw on existing constructs such as `try-except` or
`if-else`?
Or just that the additional clarity should come from  extending the loop
rather than the implicit `if`?

Mathew

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses.

References to the 
"Ocado Group" are to Ocado Group plc (registered in England and Wales with 
number 7098618) and its subsidiary undertakings (as that expression is 
defined in the Companies Act 2006) from time to time. The registered office 
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, 
Hatfield, Hertfordshire, AL10 9UL.
___
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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

On 28/07/2020 15:33, Guido van Rossum wrote:
Rest assured this is not a problem. In any case it’s the compiler, not 
the parser, that generates the bytecode, from the AST. The compiler 
always has the full AST available before it is asked to generate any 
bytecode. The new parser just allows more flexible syntactic 
constructs, esp. “soft keywords”.


*If* you want tou propose clearer syntax for this, please extend the 
loop syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense 
than ‘if [not] break’.


—Guido

On Tue, Jul 28, 2020 at 03:26 Jonathan Fine > wrote:


Hi Rob

You wrote:

So: You're asking that the bytecode generated for the for-loop
depends
on something that happens (or not) after the end of the
for-loop body
(which could be arbitrarily long).

I speak from ignorance, but I suspect that even with the new
parser,
which I am reliably informed can make the tea and implement
world peace,
that would be asking a lot.


I'm also speaking from ignorance. However, here I'm the optimist.
Ignorance is bliss. You're the pessimist. The devil is in the details.

Until we have knowledge and wisdom on this, I think we need both
points of view. So I'm grateful for your
https://en.wikipedia.org/wiki/Grain_of_salt (American English,
pinch of salt in British English). I hope it makes my dish taste
better!
-- 
Jonathan


I stand corrected; my objection to detecting "zero iterations" has no 
foundation.

It's good to know the facts.

On labelled breaks:
My God, you want to bring back the GOTO statement!:-)  Seriously, 
though, I can see that labelled breaks might be useful.  Especially 
where the same label is used more than once, helping DRY.

One thought though:
A possible, unrelated, future language extension is to allow breaking 
out of more than one loop at a time.  (I know there have been times 
where I would have found this useful, though I can't recall them now.)
So the syntax to break out of 3 loops at a time might be "break break 
break" or "break 3" or "break 3 times" or .
A syntax to break out of *all* enclosing loops (although not great 
programming style, because it would be broken by adding a new outer 
loop) might be "break all" or "break *".

(BTW I have a job lot of bikesheds, in case you want any cheap ones.)
So maybe you could give half an eye to not clashing with some such 
possible future scheme?

Rob



___
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/AHONH5PRIXOK7KY5HSP2ATGVFXAOG5JS/
Code of Conduct: http://python.org/psf/codeofconduct/

--
--Guido (mobile)


___
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/LHFXMIGA6WVKPCXHPYRRH72WXUMANFA6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Guido van Rossum]

Rest assured this is not a problem. In any case it’s the compiler, not the
parser, that generates the bytecode, from the AST. The compiler always has
the full AST available before it is asked to generate any bytecode. The new
parser just allows more flexible syntactic constructs, esp. “soft keywords”.

*If* you want tou propose clearer syntax for this, please extend the loop
syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if
[not] break’.

—Guido

On Tue, Jul 28, 2020 at 03:26 Jonathan Fine  wrote:

> Hi Rob
>
> You wrote:
>
> So:  You're asking that the bytecode generated for the for-loop depends
>> on something that happens (or not) after the end of the for-loop body
>> (which could be arbitrarily long).
>>
>
>
>> I speak from ignorance, but I suspect that even with the new parser,
>> which I am reliably informed can make the tea and implement world peace,
>> that would be asking a lot.
>>
>
> I'm also speaking from ignorance. However, here I'm the optimist.
> Ignorance is bliss. You're the pessimist. The devil is in the details.
>
> Until we have knowledge and wisdom on this, I think we need both points of
> view. So I'm grateful for your https://en.wikipedia.org/wiki/Grain_of_salt 
> (American
> English, pinch of salt in British English). I hope it makes my dish taste
> better!
> --
> Jonathan
> ___
> 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/AHONH5PRIXOK7KY5HSP2ATGVFXAOG5JS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/2PI2OCE4KWPHTO3JNIGGE4O4J43EU5U5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Jonathan Fine]

Hi Rob

You wrote:

So:  You're asking that the bytecode generated for the for-loop depends
> on something that happens (or not) after the end of the for-loop body
> (which could be arbitrarily long).
>


> I speak from ignorance, but I suspect that even with the new parser,
> which I am reliably informed can make the tea and implement world peace,
> that would be asking a lot.
>

I'm also speaking from ignorance. However, here I'm the optimist. Ignorance
is bliss. You're the pessimist. The devil is in the details.

Until we have knowledge and wisdom on this, I think we need both points of
view. So I'm grateful for your
https://en.wikipedia.org/wiki/Grain_of_salt (American
English, pinch of salt in British English). I hope it makes my dish taste
better!
-- 
Jonathan
___
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/AHONH5PRIXOK7KY5HSP2ATGVFXAOG5JS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Jonathan Fine]

Thank you Rob, for your contribution. I find it very helpful. You've raised
important implementation questions.

Regarding the no-iterations case. Suppose we have
for i in items:
loop_body
case:
zero:
print('no items to process')

In this case, the Python compiler knows that the post-iteration block
contains a 'zero:' statement. And in other cases it knows that it does not.
So why not have the compiler produce bytecode that records this fact. (This
could be done by providing an additional bytecode, or if there's room
adding a flag to an existing bytecode.)

Depending on how we choose to implement, if we wish we could keep both the
bytecode and interpreter code exactly the same, for the currently allowed
post-iteration blocks.

I apologize that it wasn't clear to you from my example code, that for
example we allow any identifier as the 'label argument' in a break
statement. As in
break error_1
break error_2
break time_out

The compiler can and I think should ensure that all labels in the
post-iteration block occur in the iteration block. And a code analysis code
aka linter should warn about unreachable code. This unreachable code
should, of course, not generate any bytecode.

Thank you again for your comment. I hope this helps.
-- 
Jonathan
___
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/QN6VMQTTQVJGUF6I6C6TEMUS57677VVZ/
Code of Conduct: http://python.org/psf/codeofconduct/