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 mailto:jfine2358@gmail.com> 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 <you-name-it>. 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 mailto:python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org mailto:python-ideas-leave@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/AHONH5... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile)

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 <label>

would handle that situation.

-- ~Ethan~ Maybe.  But note that you're extending Jonathan's proposal by allowing

On 29/07/2020 14:51, Ethan Furman wrote: 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-leave@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/LEBAC5... Code of Conduct: http://python.org/psf/codeofconduct/