[Python-Dev] Anyone else gotten bizarre personal replies to mailing list posts?

[Nathaniel Smith]

I just got the reply below sent directly to my personal account, and I'm
confused about what's going on. If it's just a one off I'll chalk it up to
random internet weirdness, but if other folks are getting these too it
might be something the list admins should look into? Or... something?

-- Forwarded message -
From: Hoi lam Poon 
Date: Fri, Apr 23, 2021, 02:01
Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
To: Nathaniel Smith 


Stop pretending, I can definitely get the key control file, your working
group, all past actions and instructions cannot be cleared in front of me
at all. You have been playing around for a few days, and I won’t stop you.
Your face? I won’t, you know, you can’t drive me away, and that file is
all, after I get it, you will be convicted even if you disband, I swear

在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：

> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum  wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> on it b/c in your last email you said you didn't understand why this
> >> was a problem :-). And except* is definitely useful. But I think there
> >> are options for 'except' that haven't been considered fully.
> >
> > Do you have any suggestions, or are you just telling us to think harder?
> Because we've already thought as hard as we could and within all the
> constraints (backwards compatibility and otherwise) we just couldn't think
> of a better one.
>
> The main possibility that I don't think we've examined fully is to
> make 'except' blocks fire multiple times when there are multiple
> exceptions. We ruled it out early b/c it's incompatible with nested
> EGs, but if flat EGs are better anyway, then the balance shifts around
> and it might land somewhere different. it's a tricky discussion
> though, b/c both the current proposal and the alternative have very
> complex implications and downsides. So we probably shouldn't get too
> distracted by that until after the flat vs nested discussion has
> settled down more.
>
> I'm not trying to filibuster here -- I really want some form of EGs to
> land. I think python has the potential to be the most elegant and
> accessible language around for writing concurrent programs, and EGs
> are a key part of that. I don't want to fight about anything; I just
> want to work together to make sure we have a full picture of our
> options, so we can be confident we're making the best choice.
>
> > The real cost here is that we would need a new "TracebackGroup" concept,
> since the internal data structures and APIs keep the traceback chain and
> the exception object separated until the exception is caught. In our early
> design stages we actually explored this and the complexity of the data
> structures was painful. We eventually realized that we didn't need this
> concept at all, and the result is much clearer, despite what you seem to
> think.
>
> I'm not talking about TracebackGroups (at least, I think I'm not?). I
> think it can be done with exactly our current data structures, nothing
> new.
>
> - When an EG is raised, build the traceback for just that EG while
> it's unwinding. This means if any C code peeks at exc_info while it's
> in flight, it'll only see the current branch of the traceback tree,
> but that seems fine.
> - When the exception is caught and we go to write back the traceback
> to its __traceback__ attribute, instead "peek through" the EG and
> append the built-up traceback entries onto each of the constituent
> exceptions.
>
> You could get cleverer for efficiency, but that basic concept seems
> pretty simple and viable to me. What am I missing?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4BAOL763Y2O2AXLEILYGHSNG2VMZJIN6/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Anyone else seeing a lack of caching in local docs builds?

[Antoine Pitrou]

On Mon, 28 Jan 2019 18:02:16 +1000
Nick Coghlan  wrote:
> On Mon, 28 Jan 2019 at 05:44, Terry Reedy  wrote:
> > On 1/27/2019 9:01 AM, Nick Coghlan wrote:  
> > > For now, I'm assuming I've messed something up with my local docs
> > > build setup, but figured I'd ask if anyone else was seeing this, in
> > > case it was actually broken at the build level (CI wouldn't pick this
> > > up, since it always builds from scratch anyway).  
> >
> > I think something is broken.  Caching used to work better.  
> 
> In my case, I had an older version of blurb installed, which was
> keeping NEWS from rendering properly, and I suspect that was
> preventing Sphinx from marking the cache as valid.
> 
> I'm not sure about that theory though, as I would have expected an
> invalid NEWS file to only keep the NEWS file from being cached.

I've often noticed oddities in Sphinx caching on other projects.
I'm not sure the algorithm is extremely precise.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Anyone else seeing a lack of caching in local docs builds?

[Nick Coghlan]

On Mon, 28 Jan 2019 at 05:44, Terry Reedy  wrote:
> On 1/27/2019 9:01 AM, Nick Coghlan wrote:
> > For now, I'm assuming I've messed something up with my local docs
> > build setup, but figured I'd ask if anyone else was seeing this, in
> > case it was actually broken at the build level (CI wouldn't pick this
> > up, since it always builds from scratch anyway).
>
> I think something is broken.  Caching used to work better.

In my case, I had an older version of blurb installed, which was
keeping NEWS from rendering properly, and I suspect that was
preventing Sphinx from marking the cache as valid.

I'm not sure about that theory though, as I would have expected an
invalid NEWS file to only keep the NEWS file from being cached.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Anyone else seeing a lack of caching in local docs builds?

[Terry Reedy]

On 1/27/2019 9:01 AM, Nick Coghlan wrote:

Hi folks,

I'm currently seeing a behaviour where every time I run "make html",
all 474 source files get rebuilt.


I just rebuilt, ditto, all 474.  Caching only works when I rebuild 
'soon' (at least within same day) after a complete rebuild.  I just 
updated and only function.rst was changed and only function.html and the 
indexes were rebuilt.



For now, I'm assuming I've messed something up with my local docs
build setup, but figured I'd ask if anyone else was seeing this, in
case it was actually broken at the build level (CI wouldn't pick this
up, since it always builds from scratch anyway).


I think something is broken.  Caching used to work better.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Anyone else seeing a lack of caching in local docs builds?

[Nick Coghlan]

Hi folks,

I'm currently seeing a behaviour where every time I run "make html",
all 474 source files get rebuilt.

For now, I'm assuming I've messed something up with my local docs
build setup, but figured I'd ask if anyone else was seeing this, in
case it was actually broken at the build level (CI wouldn't pick this
up, since it always builds from scratch anyway).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Larry Hastings]

As previously requested: please take this discussion to python-ideas.  
If you reply, remove python-dev from the To: and Cc: lists, and add 
python-ideas instead.  This speculative discussion was never appropriate 
for python-dev.



//arry/


On 07/28/2017 03:11 PM, Rob Cliffe wrote:



On 28/07/2017 20:57, MRAB wrote:

On 2017-07-28 10:17, Michel Desmoulin wrote:

elif break and elif None: I'd like that very much. It's weird a break
the semantic of break and None, but it's in such a dark corner of 
Python

anyway I don't bother.


Surely it would not be "elif break", but "elif not break"?
To me, anything beginning with "else" or "elif" suggests an 
alternative branch, not an additional one (YMMV):

if condition:
do_something
else:
do_something_completely_different

Therefore I would find "if not break" or even "and if not break" more 
intuitive.

Best wishes
Rob Cliffe




Le 27/07/2017 à 21:19, MRAB a écrit :

On 2017-07-27 03:34, Mike Miller wrote:



On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to
it, to
remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, 
congrats. Perhaps in

Python 5 it can be enabled, with for-else: used instead for empty
iterables, as
that's what I expected the first few dozen times.


For empty iterables, how about "elif None:"? :-)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com



---
This email has been checked for viruses by AVG.
http://www.avg.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/larry%40hastings.org


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Rob Cliffe]

On 28/07/2017 20:57, MRAB wrote:

On 2017-07-28 10:17, Michel Desmoulin wrote:

elif break and elif None: I'd like that very much. It's weird a break
the semantic of break and None, but it's in such a dark corner of Python
anyway I don't bother.


Surely it would not be "elif break", but "elif not break"?
To me, anything beginning with "else" or "elif" suggests an alternative 
branch, not an additional one (YMMV):

if condition:
do_something
else:
do_something_completely_different

Therefore I would find "if not break" or even "and if not break" more 
intuitive.

Best wishes
Rob Cliffe




Le 27/07/2017 à 21:19, MRAB a écrit :

On 2017-07-27 03:34, Mike Miller wrote:



On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to
it, to
remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats. 
Perhaps in

Python 5 it can be enabled, with for-else: used instead for empty
iterables, as
that's what I expected the first few dozen times.


For empty iterables, how about "elif None:"? :-)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com



---
This email has been checked for viruses by AVG.
http://www.avg.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[MRAB]

On 2017-07-28 10:17, Michel Desmoulin wrote:

elif break and elif None: I'd like that very much. It's weird a break
the semantic of break and None, but it's in such a dark corner of Python
anyway I don't bother.


Surely it would not be "elif break", but "elif not break"?


Le 27/07/2017 à 21:19, MRAB a écrit :

On 2017-07-27 03:34, Mike Miller wrote:



On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to
it, to
remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats. 
Perhaps in

Python 5 it can be enabled, with for-else: used instead for empty
iterables, as
that's what I expected the first few dozen times.


For empty iterables, how about "elif None:"? :-)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Michel Desmoulin]

elif break and elif None: I'd like that very much. It's weird a break
the semantic of break and None, but it's in such a dark corner of Python
anyway I don't bother.

Le 27/07/2017 à 21:19, MRAB a écrit :
> On 2017-07-27 03:34, Mike Miller wrote:
>>
>>
>> On 2017-07-26 16:36, MRAB wrote:
>>> "nobreak" would introduce a new keyword, but "not break" wouldn't.
>>
>> Whenever I've used the for-else, I've put a # no-break right next to
>> it, to
>> remind myself as much as anyone else.
>>
>> for...: not break: is the best alternative I've yet seen, congrats. 
>> Perhaps in
>> Python 5 it can be enabled, with for-else: used instead for empty
>> iterables, as
>> that's what I expected the first few dozen times.
>>
> For empty iterables, how about "elif None:"? :-)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/desmoulinmichel%40gmail.com
> 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Eric Lafontaine]

funny ;

this made me think of this talk;
https://youtu.be/OSGv2VnC0go?t=1013


Éric Lafontaine |  Membre du Projet VUE, Groupe Contrôle
Génie électrique, 54ème promotion UdeS | Étudiant en maitrise TI à l'ETS
VAS OPS chez Bell Mobility

« Nous voulons proposer une alternative de transport en présentant un
véhicule électrique spécifiquement conçu pour les déplacements urbains. »

2017-07-27 15:19 GMT-04:00 MRAB :

> On 2017-07-27 03:34, Mike Miller wrote:
>
>>
>>
>> On 2017-07-26 16:36, MRAB wrote:
>>
>>> "nobreak" would introduce a new keyword, but "not break" wouldn't.
>>>
>>
>> Whenever I've used the for-else, I've put a # no-break right next to it,
>> to
>> remind myself as much as anyone else.
>>
>> for...: not break: is the best alternative I've yet seen, congrats.
>> Perhaps in
>> Python 5 it can be enabled, with for-else: used instead for empty
>> iterables, as
>> that's what I expected the first few dozen times.
>>
>> For empty iterables, how about "elif None:"? :-)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric.
> lafontaine1%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[MRAB]

On 2017-07-27 03:34, Mike Miller wrote:



On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to it, to
remind myself as much as anyone else.

for...: not break: is the best alternative I've yet seen, congrats.  Perhaps in
Python 5 it can be enabled, with for-else: used instead for empty iterables, as
that's what I expected the first few dozen times.


For empty iterables, how about "elif None:"? :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Mike Miller]

On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to it, to 
remind myself as much as anyone else.


for...: not break: is the best alternative I've yet seen, congrats.  Perhaps in 
Python 5 it can be enabled, with for-else: used instead for empty iterables, as 
that's what I expected the first few dozen times.


-Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Terry Reedy]

This discussion belongs on python-list (where is it mostly a repeat).

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[MRAB]

On 2017-07-27 01:07, Koos Zevenhoven wrote:
On Jul 27, 2017 02:38, "MRAB" > wrote:


On 2017-07-26 23:55, Koos Zevenhoven wrote:


​IMO,

for item in sequence:
 # block
nobreak:   # or perhaps `if not break:`
 # block

would be clearer (if the syntax is necessary at all).


You couldn't have "if not break:" because that would look like the
start of an 'if' statement.


Do you mean as an implementation issue or for human readability?

I suppose you _could_ use "if not break:", but as 'if' normally 
indicates the start of an 'if' statement, you would get complaints about 
it! :-)


Maybe it would be clearer if it was "elif not break:". :-)


"nobreak" would introduce a new keyword, but "not break" wouldn't.


Sure :)



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Koos Zevenhoven]

On Jul 27, 2017 02:38, "MRAB"  wrote:

On 2017-07-26 23:55, Koos Zevenhoven wrote:

>
> ​IMO,
>
> for item in sequence:
>  # block
> nobreak:   # or perhaps `if not break:`
>  # block
>
> would be clearer (if the syntax is necessary at all).
>

You couldn't have "if not break:" because that would look like the start of
an 'if' statement.


Do you mean as an implementation issue or for human readability?

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Sure :)

-- Koos (mobile)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[MRAB]

On 2017-07-26 23:55, Koos Zevenhoven wrote:
On Mon, Jul 24, 2017 at 7:14 PM, Steven D'Aprano >wrote:


Hello Kiuhnm, and welcome.

On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
> Hello,
>
> I think that the expression "for...else" or "while...else" is completely
> counter-intuitive.


You may be right -- this has been discussed many, many times before. In
my personal opinion, the best (and only accurate!) phrase would have
been:

for item in sequence:
 # block
then:
 # block


​IMO,

for item in sequence:
 # block
nobreak:   # or perhaps `if not break:`
 # block

would be clearer (if the syntax is necessary at all).


[snip]

You couldn't have "if not break:" because that would look like the start 
of an 'if' statement.


"nobreak" would introduce a new keyword, but "not break" wouldn't.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Koos Zevenhoven]

On Mon, Jul 24, 2017 at 7:14 PM, Steven D'Aprano 
wrote:

> Hello Kiuhnm, and welcome.
>
> On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
> > Hello,
> >
> > I think that the expression "for...else" or "while...else" is completely
> > counter-intuitive.
>
>
> You may be right -- this has been discussed many, many times before. In
> my personal opinion, the best (and only accurate!) phrase would have
> been:
>
> for item in sequence:
> # block
> then:
> # block
>
>
​IMO,

for item in sequence:
# block
nobreak:   # or perhaps `if not break:`
# block

would be clearer (if the syntax is necessary at all).


​[...]


> ​
>
> > Wouldn't it be possible to make it clearer? Maybe
> > something like
>
> At this point, no, it is not practical to change the syntax used. Maybe
> when Python 3.0 was first introduced, but that ship has long sailed. It
> is very, very unlikely that the syntax for this will ever change, but if
> it does, it probably won't be until something in the distant future like
> Python 5.
>

​I don't have a strong opinion on this particular case, but if something
like this is changed in Python 5, I think the decision should be made much
earlier (now?) so that the old else syntax could be discouraged (and new
syntax potentially already introduced). The same thing would apply to many
other "possibly in Python 5" changes, where there is no reason to expect
that the situation is somehow different years later.

-- Koos


>
> But not Python 4: Guido has already ruled that Python 4 will not include
> major backwards-incompatible changes. Going from 3 to 4 will not be as
> disruptive as going from 2 to 3.
>
>
​[...]​


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Rob Cliffe]

On 25/07/2017 06:51, Nick Coghlan wrote:

On 25 July 2017 at 02:23, Ben Hoyt  wrote:

This is more of a python-ideas discussion, and Steven's answer is good.

I'll just add one thing. Maybe it's obvious to others, but I've liked
for...else since I found a kind of mnemonic to help me remember when the
"else" part happens: I think of it not as "for ... else" but as "break ...
else" -- saying it this way makes it clear to me that the break goes with
the else. "If this condition inside the loop is true, break. ... *else* if
we didn't break, do this other thing after the loop."

For folks looking for a more in-depth explanation of the
"if-break-else" approach to thinking about this construct:
http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html

A helpful explanation.
But that it is necessary at all underlines that (IMHO) this use of 
'else' is unnatural and hard to understand.  I always have to think 
twice about it, whether reading it or using it myself.  Therefore I 
would have preferred a more obvious keyword such as 'ifnobreak' (others 
may think of something better).

But as has been stated, it's not going to change.
Rob Cliffe



That article also has a note explaining that we're unlikely to ever
change this: 
http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html#but-couldn-t-python-be-different

Cheers,
Nick.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Nick Coghlan]

On 25 July 2017 at 02:23, Ben Hoyt  wrote:
> This is more of a python-ideas discussion, and Steven's answer is good.
>
> I'll just add one thing. Maybe it's obvious to others, but I've liked
> for...else since I found a kind of mnemonic to help me remember when the
> "else" part happens: I think of it not as "for ... else" but as "break ...
> else" -- saying it this way makes it clear to me that the break goes with
> the else. "If this condition inside the loop is true, break. ... *else* if
> we didn't break, do this other thing after the loop."

For folks looking for a more in-depth explanation of the
"if-break-else" approach to thinking about this construct:
http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html

That article also has a note explaining that we're unlikely to ever
change this: 
http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html#but-couldn-t-python-be-different

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Isaac Morland]

The way I remember it is to observe that the following are *almost* exactly
the same thing:

if C:
T
else:
E

while C:
T
else:
E

The *only* differences are:

1) where execution jumps if it reaches the end of the T: in the "while", it
jumps back to the while itself, resulting in the condition being rechecked,
whereas in the "if" execution skips over the "else" to whatever follows; and

2) in the "while", inside the T "break" and "continue" relate to this
control structure rather than to a containing loop.

(At least I don't think I'm missing any other differences!)

Seen this way, the meaning of the "else" is easy to understand and to
remember.

And the for loop else is like the while loop else.


On 24 July 2017 at 11:35, Kiuhnm via Python-Dev 
wrote:

> Hello,
>
> I think that the expression "for...else" or "while...else" is completely
> counter-intuitive. Wouldn't it be possible to make it clearer? Maybe
> something like
>
> break in for i in range(n):
>   ...
>   if cond:
> break
> else:
>   ...
>
> I'm not an English native speaker so I don't know whether "break in" is
> acceptable English in this context or can only mean "to get into a building
> by force".
>
> Kiuhnm
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/isaac.
> morland%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Alexander Belopolsky]

On Mon, Jul 24, 2017 at 12:23 PM, Ben Hoyt  wrote:
> .. I found a kind of mnemonic to help me remember when the
> "else" part happens: I think of it not as "for ... else" but as "break ...
> else" -- saying it this way makes it clear to me that the break goes with
> the else. "If this condition inside the loop is true, break. ... *else* if
> we didn't break, do this other thing after the loop."

Note that since break itself is typically guarded by an "if" as in

for i in x:
...
if cond(i):
break
...
else:
...

you can match the "else" above to the "if" inside the loop.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Ben Hoyt]

This is more of a python-ideas discussion, and Steven's answer is good.

I'll just add one thing. Maybe it's obvious to others, but I've liked
for...else since I found a kind of mnemonic to help me remember when the
"else" part happens: I think of it not as "for ... else" but as "break ...
else" -- saying it this way makes it clear to me that the break goes with
the else. "If this condition inside the loop is true, break. ... *else* if
we didn't break, do this other thing after the loop."

-Ben

On Mon, Jul 24, 2017 at 12:14 PM, Steven D'Aprano 
wrote:

> Hello Kiuhnm, and welcome.
>
> On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
> > Hello,
> >
> > I think that the expression "for...else" or "while...else" is completely
> > counter-intuitive.
>
>
> You may be right -- this has been discussed many, many times before. In
> my personal opinion, the best (and only accurate!) phrase would have
> been:
>
> for item in sequence:
> # block
> then:
> # block
>
> If you look at the byte-code generated by a for...else statement, you
> see that the "else" block is unconditionally executed after the for loop
> completes, unless something causes a jump outside of the entire
> statement: return, break, or raise. So it is more like:
>
> - run the loop;
> - *then* run the following block
>
> rather than:
>
> - run the loop;
> - otherwise ("else") run the following block.
>
> Others disagree and would prefer other keywords. But regardless,
> backwards compatibility means that we must keep "for...else", so I'm
> afraid that discussing alternatives is *almost certainly* a waste of
> time.
>
>
> > Wouldn't it be possible to make it clearer? Maybe
> > something like
>
> At this point, no, it is not practical to change the syntax used. Maybe
> when Python 3.0 was first introduced, but that ship has long sailed. It
> is very, very unlikely that the syntax for this will ever change, but if
> it does, it probably won't be until something in the distant future like
> Python 5.
>
> But not Python 4: Guido has already ruled that Python 4 will not include
> major backwards-incompatible changes. Going from 3 to 4 will not be as
> disruptive as going from 2 to 3.
>
> So depending on how you look at it: discussing alternative syntax to
> for...else is either ten years too late or ten years too early.
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> benhoyt%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] for...else

[Steven D'Aprano]

Hello Kiuhnm, and welcome.

On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote:
> Hello,
> 
> I think that the expression "for...else" or "while...else" is completely 
> counter-intuitive.


You may be right -- this has been discussed many, many times before. In 
my personal opinion, the best (and only accurate!) phrase would have 
been:

for item in sequence:
# block
then:
# block

If you look at the byte-code generated by a for...else statement, you 
see that the "else" block is unconditionally executed after the for loop 
completes, unless something causes a jump outside of the entire 
statement: return, break, or raise. So it is more like:

- run the loop;
- *then* run the following block

rather than:

- run the loop;
- otherwise ("else") run the following block.

Others disagree and would prefer other keywords. But regardless, 
backwards compatibility means that we must keep "for...else", so I'm 
afraid that discussing alternatives is *almost certainly* a waste of 
time.


> Wouldn't it be possible to make it clearer? Maybe 
> something like

At this point, no, it is not practical to change the syntax used. Maybe 
when Python 3.0 was first introduced, but that ship has long sailed. It 
is very, very unlikely that the syntax for this will ever change, but if 
it does, it probably won't be until something in the distant future like 
Python 5.

But not Python 4: Guido has already ruled that Python 4 will not include 
major backwards-incompatible changes. Going from 3 to 4 will not be as 
disruptive as going from 2 to 3.

So depending on how you look at it: discussing alternative syntax to 
for...else is either ten years too late or ten years too early.



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] for...else

[Kiuhnm via Python-Dev]

Hello,

I think that the expression "for...else" or "while...else" is completely 
counter-intuitive. Wouldn't it be possible to make it clearer? Maybe 
something like


break in for i in range(n):
  ...
  if cond:
break
else:
  ...

I'm not an English native speaker so I don't know whether "break in" is 
acceptable English in this context or can only mean "to get into a 
building by force".


Kiuhnm
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com