On 2022-10-22 15:04:58 +0200, Peter J. Holzer wrote:
> On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:
> > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote:
> > > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > > > http://literateprogramming.com/
> > >
> > > Right. That's one of
the fuck?
On Sat, Oct 22, 2022 at 9:06 AM Peter J. Holzer wrote:
> On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:
> > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote:
> > > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > > > http://literateprogramming.com/
> > >
> > > Right.
On 2022-10-22 15:04:58 +0200, Peter J. Holzer wrote:
> On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:
> > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote:
> > > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > > > http://literateprogramming.com/
> > >
> > > Right. That's one of
On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:
> On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote:
> > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > > http://literateprogramming.com/
> >
> > Right. That's one of the inspirations for my comment.
> >
> > But literate programming
On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote:
>
> On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > > which had special combinations for all the BASIC keywords). And if you
> > > go this way, why not go a step further and dissociate the program from
> > > its linear text
On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:
> > which had special combinations for all the BASIC keywords). And if you
> > go this way, why not go a step further and dissociate the program from
> > its linear text representation? Add footnotes, different views,
> > hyperlinks, format
wrote:
> I had another crazy thought that I AM NOT ASKING anyone to do. OK?
>
> I was wondering about a sort of catch method you could use that generates a
> pseudo-signal only when the enclosed preceding loop exits normally as a
> sort of way to handle the ELSE need without the u
On Wed, 12 Oct 2022 23:19:39 +0100, Rob Cliffe
declaimed the following:
>I too have occasionally used for ... else. It does have its uses. But
>oh, how I wish it had been called something else more meaningful,
>whether 'nobreak' or whatever. It used to really confuse me.
> which had special combinations for all the BASIC keywords). And if you
> go this way, why not go a step further and dissociate the program from
> its linear text representation? Add footnotes, different views,
> hyperlinks, format mathematical expressions like formulas, etc.
On Mon, 17 Oct 2022 at 16:36, Antoon Pardon wrote:
>
>
>
> Op 17/10/2022 om 04:01 schreef Chris Angelico:
> > On Mon, 17 Oct 2022 at 10:46, wrote:
> >> My point Chris was that you can have a conversation where you are exploring
> >> and not proposing. Brainstorming, perhaps.
> > And my point is
Op 17/10/2022 om 04:01 schreef Chris Angelico:
On Mon, 17 Oct 2022 at 10:46, wrote:
My point Chris was that you can have a conversation where you are exploring
and not proposing. Brainstorming, perhaps.
And my point is that either a proposal is a serious one that can
expect serious
uch as an extra optional argument that is called
> if the loop exits from the bottom. The code you now put in the ELSE clause
> might have to be in the lambda or whatever. That may not be a good fit for
> Python.
If you're inventing a completely new language, you can do whatever you
like, but
the bottom. The code you now put in the ELSE clause
might have to be in the lambda or whatever. That may not be a good fit for
Python.
What may aggravate you is that lots of people keep telling you that the ELSE
on a loop feature is not intuitive to many, sometimes even after it is
explained.
My
On Mon, 17 Oct 2022 at 08:22, wrote:
> I had another crazy thought that I AM NOT ASKING anyone to do. OK?
>
Here's another proposal: Let's ban you from this mailing list. Don't
worry, I AM NOT ASKING anyone to do it. OK?
Do you see how ridiculous and pointless it is to have proposals with
that
them in even
using ASCII keyboards for some level of compatibility.
The original topic asked about the topic of re-using ELSE as a known keyword
in a context I and some others feel is a stretch. But the alterative could
be to add an ever increasing number of keywords to meet new needs.
I had
On 2022-10-16 19:52:47 +0200, Antoon Pardon wrote:
> Op 16/10/2022 om 19:01 schreef Peter J. Holzer:
> > On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:
> > > Op 16/10/2022 om 00:50 schreefavi.e.gr...@gmail.com:
> > > > That might not easily solve this problem. But I wonder if reserving
> > > >
imagine a customized
compiler or interpreter that uses key words in the local language
instead of for or while or if or else or even import.
Please, please please... forget about that idea.
I know examples. They had no future, and have no future. Either RMS or
ESR once have written in one
Op 16/10/2022 om 19:01 schreef Peter J. Holzer:
On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:
Op 16/10/2022 om 00:50 schreefavi.e.gr...@gmail.com:
That might not easily solve this problem. But I wonder if reserving
some kind of prefix might help, so anything like extension.0nNoBreak
or interpreter that uses key words in the local language
instead of for or while or if or else or even import.
If a region of UNICODE was set aside, would it have to be as a sort of
additional ALT or shift key for anything, or just English characters
or would it be for abstract symbols that would be mapped
Op 16/10/2022 om 19:03 schreef Chris Angelico:
On Mon, 17 Oct 2022 at 03:57, Antoon Pardon wrote:
Op 16/10/2022 om 17:05 schreef Chris Angelico:
On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote:
Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect
hon-list On
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, October 12, 2022 6:20 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
I too have occasionally used for ... else. It does have its uses. But oh, how I wish it had been
called something else more
On Mon, 17 Oct 2022 at 03:57, Antoon Pardon wrote:
>
>
> Op 16/10/2022 om 17:05 schreef Chris Angelico:
> > On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote:
> >> Why would I need good luck? I expressed an idea and you didn't like it.
> >> That won't affect my life in a meaningful way.
> >
On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:
> Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com:
> > That might not easily solve this problem. But I wonder if reserving
> > some kind of prefix might help, so anything like extension.0nNoBreak
> > could be added to a loop as a final clause
Op 16/10/2022 om 17:05 schreef Chris Angelico:
On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote:
Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect my life in a meaningful way.
Well, with that attitude, it's not going to affect anyone else's life
On Sun, 16 Oct 2022 at 22:47, Antoon Pardon wrote:
>
>
>
> Op 16/10/2022 om 13:03 schreef Chris Angelico:
> > On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote:
> >
> >> My idea would be to reserve different unicode blocks for the keywords
> >> and the identifiers. e.g. We could reserve the
instead of for or
while or if or else or even import.
If a region of UNICODE was set aside, would it have to be as a sort of
additional ALT or shift key for anything, or just English characters or
would it be for abstract symbols that would be mapped to and from a long
list of reserved key words
Op 16/10/2022 om 13:03 schreef Chris Angelico:
On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote:
My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric
block for keywords and all other letters and
On Sun, 16 Oct 2022 at 21:19, Antoon Pardon wrote:
>
> Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com:
> > This has been discussed so often precisely because I swear NO CHOICE of
> > keyword would satisfy everybody! Most languages start with designated
> > keywords and some reserve a few
Op 16/10/2022 om 00:50 schreef avi.e.gr...@gmail.com:
This has been discussed so often precisely because I swear NO CHOICE of keyword
would satisfy everybody! Most languages start with designated keywords and some
reserve a few for later use. But then things can get frozen in place to avoid
d of sorts.
-Original Message-
From: Python-list On
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, October 12, 2022 6:20 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
I too have occasionally used for ... else. It does have its uses. But oh, h
On 2022-10-12, Rob Cliffe via Python-list wrote:
> I too have occasionally used for ... else. It does have its uses. But
> oh, how I wish it had been called something else more meaningful,
> whether 'nobreak' or whatever.
I use it a few times year. I have to look it up in the docu
I too have occasionally used for ... else. It does have its uses. But
oh, how I wish it had been called something else more meaningful,
whether 'nobreak' or whatever. It used to really confuse me. Now I've
learned to mentally replace "else" by "if nobreak", it confuses
On 11/10/2022 02.13, Grant Edwards wrote:
On 2022-10-10, Chris Angelico wrote:
On Mon, 10 Oct 2022 at 11:52, MRAB wrote:
On 2022-10-10 00:40, dn wrote:
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
wrote:
"shortest block first"
Have never heard this advice before. Kind-of
eed to save puzzles "what this
> > hanging else belongs to?"
>
> If you find yourself asking that question, the if-block is probably too long
> to
> begin with.
ACK.
> > Code small things first and return early, same
level allows everybody to view the file in their preferred
layout.
I have, however, found out that this requires more discipline than I and
the people I work with can muster. There is always someone who
accidentally converts some tabs to spaces, messing up indentation for
everyone else. So I r
As did I.
tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")
I think there are other places I could be using it, but
On 10/10/2022 06:15, avi.e.gr...@gmail.com wrote:
Chris, a short(er) answer to your addition below.
I did not at first share your perception but maybe do now. If the argument
was that ELSE and other constructs like FINALLY or CATCH are horrible
because they follow other code and important
On 2022-10-11, wrote:
> But is that native python or some extension where "|" has been modified to
> mean something other than a form of OR in some places?
The latter.
> What module do you need to load to make that happen?
The provided link is for a page that shows the module and explains
On 10/10/2022 16.19, avi.e.gr...@gmail.com wrote:
I won't reply to everything Dave says and especially not the parts I fully
agree with.
I think in many situations in life there is no ONE way to do things so most
advice is heuristic at best and many exceptions may exist depending on your
a harder-to-read way. If the syntax
change allows a pipe symbol so it can be written infix, that helps
programmers who prefer to think more linearly.
But since the original topic here was loosely about loops and the silly
choice (there was no great choice) of re-using the ELSE keyword, I note how
commonl
Op 10/10/2022 om 04:38 schreef avi.e.gr...@gmail.com:
[This is an answer for Peter and can easily be skipped by those who know or
have no wish to.]
Strictly speaking Peter, the word "pipe" may not mean quite something in
Python but other concepts like chaining may be better.
The original
On 09/10/2022 15.02, Peter J. Holzer wrote:
On 2022-10-09 15:32:13 -0400, Avi Gross wrote:
and of course no pipelines.
Since you've now used that term repeatedly: What is a pipeline in
Python?
Could it be what's discussed starting on page 35 of this presentation?
Axy wrote:
>> Also not really a justification for "shortest block first". Wanting
>> some elaboration on that. What's the value in it?
>
> Well, the value is productivity. No need to save puzzles "what this
> hanging else belongs to?"
If you find yo
ock first.
>
> I usually put the most expected / frequent / not negated block first if the
> whole if/else statement is not "too long". Sometimes whatever you want to do
> becomes pointless if a certain conditions is not met, in which case I do an
> early break or
Grant Edwards wrote:
> I've followed that advice for several decades. I find it much easier
> to read code that's organized that way -- particularly when the
> difference in block sizes is large (e.g. the first block is one line,
> and the second is a a hundred).
If any conditionally executed
Axy 在 2022年10月10日 星期一下午5:55:29 [UTC+8] 的信中寫道：
> On 09/10/2022 03:33, Jach Feng wrote:
> > The else is always coming with the break, not the for.
> However, the compiler does not complain.
Sure, the compiler will not complain even in a IOCCC contest:-)
> > but the [for
Chris Angelico wrote:
> Yes, I'm aware that code readability becomes irrelevant for
> short-duration projects. Beside the point. I'm wondering how important
> it really is to have the shortest block first.
I usually put the most expected / frequent / not negated block first if the
whol
On 2022-10-10, Calvin Spealman wrote:
> On Sat, Oct 8, 2022 at 5:35 PM rbowman wrote:
>> On 10/7/22 21:32, Axy wrote:
>> > So, seriously, why they needed else if the following pieces produce same
>> > result? Does anyone know or remember their motivation?
>>
I just want to get clear on what may be a side issue
The suggestion is that a loop with an ELSE clause only makes sense if the
user can BREAK out without finishing, right?
My first question is whether a warning or even error makes sense if there is
no BREAK statement anywhere in the loop
On 2022-10-09 22:38:28 -0400, avi.e.gr...@gmail.com wrote:
> [This is an answer for Peter and can easily be skipped by those who know or
> have no wish to.]
>
> Strictly speaking Peter, the word "pipe" may not mean quite something in
> Python but other concepts like chaining may be better.
>
>
On 2022-10-10 12:40:44 +1300, dn wrote:
> On 10/10/2022 05.56, Peter J. Holzer wrote:
> > On 2022-10-09 12:18:09 -0400, Avi Gross wrote:
> > > Some would argue for a rule related to efficiency of execution. When you
> > > have multiple blocks as in an if-else or c
On 10/10/2022 19:25, Weatherby,Gerard wrote:
pylint, at least, provides a warning:
fe.py:4:0: W0120: Else clause on loop without a break statement
(useless-else-on-loop)
I'm using flake8, it does not, alas.
Axy.
--
https://mail.python.org/mailman/listinfo/python-list
pylint, at least, provides a warning:
fe.py:4:0: W0120: Else clause on loop without a break statement
(useless-else-on-loop)
sum = 0
for i in range(5):
sum += i
else:
print("Always executes")
print(sum)
From: Python-list on
behalf of Axy via Python-list
Date: Monday,
On 10/10/2022 15:52, Weatherby,Gerard wrote:
I wonder if for/else could have been less confusing if it was
referred to
as for-break-else and if the else clause was only valid syntax if the
for
loop actually contained a break statement in the first place.
Sounds reasonable. It would
On 10/10/2022 15:52, Weatherby,Gerard wrote:
Core developer Raymond Hettinger explains the history starting at 15:40
https://www.youtube.com/watch?v=OSGv2VnC0go
(which I found on stackoverflow
https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops
Core developer Raymond Hettinger explains the history starting at 15:40
https://www.youtube.com/watch?v=OSGv2VnC0go
(which I found on stackoverflow
https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops
)
TL:DR
The “else” is a historical artificial from
On Sat, Oct 8, 2022 at 5:35 PM rbowman wrote:
> On 10/7/22 21:32, Axy wrote:
> > So, seriously, why they needed else if the following pieces produce same
> > result? Does anyone know or remember their motivation?
>
> In real scenarios there would be more logic in the for bl
try:
open(disk)
except:
error(“Can’t open disk”)
lots of things
From: Python-list on
behalf of Karsten Hilbert
Date: Monday, October 10, 2022 at 5:46 AM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
*** Attention
On 2022-10-10, Chris Angelico wrote:
> On Mon, 10 Oct 2022 at 11:52, MRAB wrote:
>>
>> On 2022-10-10 00:40, dn wrote:
>> > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
>> > wrote:
>> >
>> >> "shortest block first"
>> >
>> > Have never heard this advice before. Kind-of rankled with me, as it
On Mon, 10 Oct 2022 at 22:37, Axy via Python-list
wrote:
>
>
> On 10/10/2022 12:24, Chris Angelico wrote:
> > On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
> > wrote:
> >>
> >>> Not sure what you mean, but a for-else without a break is quite
> &
On 10/10/2022 12:24, Chris Angelico wrote:
On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
wrote:
Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?
The else is associated with the break to the exact extent that one is
essential
On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
wrote:
>
>
> > Not sure what you mean, but a for-else without a break is quite
> > useless. What exactly ARE you arguing here?
> >
> > The else is associated with the break to the exact extent that one is
>
Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?
The else is associated with the break to the exact extent that one is
essential to the other's value.
I'm not arguing. That was just for the record, how things are done in
Python
On Mon, 10 Oct 2022 at 20:56, Axy via Python-list
wrote:
>
> > The else is always coming with the break, not the for.
> However, the compiler does not complain.
> > There are [for ...], [for...break...], and[for...break...else],
>
> That's implied and contradict
On Mon, 10 Oct 2022 at 20:46, Karsten Hilbert wrote:
>
> Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram:
>
> > I often follow this rule. For me, it's about readability. Compare:
> >
> > if not open( disk ):
> > error( "Can't open disk&quo
On 09/10/2022 03:33, Jach Feng wrote:
Axy 在 2022年10月8日 星期�
�上午11:39:44 [UTC+8] 的信中寫道：
Hi there,
this is rather a philosophical question, but I assume I miss something.
I don't remember I ever used else clause for years I was with python and
my expectation was it executed only if the the main
Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram:
> I often follow this rule. For me, it's about readability. Compare:
>
> if not open( disk ):
> error( "Can't open disk" )
> else:
> printf( "now imagine there's some larger block here&qu
Axy 在 2022年10月8日 星期六上午11:39:44 [UTC+8] 的信中寫道：
> Hi there,
>
> this is rather a philosophical question, but I assume I miss something.
> I don't remember I ever used else clause for years I was with python and
> my expectation was it executed only if the the main body was never r
On 10/8/22 22:37, Axy wrote:
Python is awesome because it's semantic is clear for the majority, but
there are places that look odd. In case of "for", "else" looks logically
tied with "for" clause, but actually it is not. It's tied with "break"
state
Chris, a short(er) answer to your addition below.
I did not at first share your perception but maybe do now. If the argument
was that ELSE and other constructs like FINALLY or CATCH are horrible
because they follow other code and important things should be first, that is
a silly argument. Many
hat most of
us disagree that it's even good advice. So, it's not really a good
argument against for-else.
> I have studied PHP but have never felt a need to use it and arguably the
> roles it has played are often done commonly by other programs or methods.
That's because PHP is terrible.
> So
t your code should
declare all imports in alphabetical order then declare all functions in
alphabetical order, they can not only safely be ignored, but perhaps not
taken seriously as imports sometimes need to be done carefully if something
needs something else and if a language needs functions to be defined b
complex nested IF-THEN-ELSE structures or CASE statements and so on such
as comprehensions as to what ways produce better results much of the time and
when another method is better.
Someone suggested a method they use that others wondered about. But they have a
point. If you make code with large
eter J. Holzer
Sent: Sunday, October 9, 2022 4:02 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?
On 2022-10-09 15:32:13 -0400, Avi Gross wrote:
> and of course no pipelines.
Since you've now used that term repeatedly: What is a pipeline in
On Mon, 10 Oct 2022 at 11:52, MRAB wrote:
>
> On 2022-10-10 00:40, dn wrote:
> > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
> > wrote:
> >
> >> "shortest block first"
> >
> > Have never heard this advice before. Kind-of rankled with me, as it did
> > for others.
> >
> > Enquiring minds
"""It is recommended to create conditions so that the shortest block of
code goes first."""
Thanks for this!
So, a Domain-Specific Language for a CMS.
If this is only reference, then hardly a tenet of ComSc thinking or
programming-languages!
For fun: Typo3 is based on PH
On 2022-10-10 00:40, dn wrote:
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
wrote:
"shortest block first"
Have never heard this advice before. Kind-of rankled with me, as it did
for others.
Enquiring minds want to know... Played Duck, duck, go on this: zero hits
amongst a pile of
!) have used or heard the term.
Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the
On 2022-10-09 15:32:13 -0400, Avi Gross wrote:
> and of course no pipelines.
Since you've now used that term repeatedly: What is a pipeline in
Python?
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |
Peter,
There can be excellent reasons to undo a pipeline like I described. I often
write it carefully in smaller chunks while debugging and make it more
elegant later ...
But someone amused me by explaining they were going to let people believe
the code was written by them so it had to fit their
Fair enough, Chris. There may be some overlap with the size of code for the
most common cases but sometimes the opposite as those may be more complex
to deal with.
A reality for many programmers today is to not micromanage too early as
things are often fast enough and any tweaking is best done
On 2022-10-09 12:34:22 -0400, Avi Gross wrote:
> I have seen programmers who have taken an elegant pipeline I have built
> apart and made it into many lines of code reassignment the value of each
> step to the same or different variables and other ways of lengthening or
> obscuring my intent.
I
On 2022-10-09 12:18:09 -0400, Avi Gross wrote:
> Smallest code blocks first may be a more modern invention.
>
> Some would argue for a rule related to efficiency of execution. When you
> have multiple blocks as in an if-else or case statement with multiple
> choices, that you
if you're paid for SLOC :-)))
By the way, does "else" clause after affect cyclomatic complexity
metric? I mean "for" loops.
Axy.
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, 10 Oct 2022 at 03:46, Avi Gross wrote:
>
> Chris, I was not arguing that at all.
Maybe not intentionally, but you did lend a lot of weight to that argument :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
rule related to efficiency of execution. When you
> > have multiple blocks as in an if-else or case statement with multiple
> > choices, that you order the most common cases first. Those shorten
> > execution more often than the rarer cases especially the ones that should
> >
. Holzer wrote:
> On 2022-10-09 05:37:59 +0100, Axy via Python-list wrote:
> > Actually the reason I never used "else" was the violation of the rule
> > of beauty "shortest block first".
>
> That's a weird rule.
>
> I can see justifications for "mo
On Mon, 10 Oct 2022 at 03:22, Avi Gross wrote:
>
> Smallest code blocks first may be a more modern invention.
>
> Some would argue for a rule related to efficiency of execution. When you
> have multiple blocks as in an if-else or case statement with multiple
> choices, that
Am Sun, Oct 09, 2022 at 05:37:59AM +0100 schrieb Axy via Python-list:
> Python is awesome because it's semantic is clear for the majority, but there
> are places
> that look odd. In case of "for", "else" looks logically tied with "for"
> clause, but
&
Smallest code blocks first may be a more modern invention.
Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than
>Well, the value is productivity. No need to save puzzles "what this
>hanging else belongs to?"
if you get to the point where it's hard to tell which else lines up with
which if or for statement, I would suggest breaking things out into
well-named helper functions rather th
On 2022-10-09 05:37:59 +0100, Axy via Python-list wrote:
> Actually the reason I never used "else" was the violation of the rule
> of beauty "shortest block first".
That's a weird rule.
I can see justifications for "most common case first" and "most sp
me elaboration on that. What's the value in it?
Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?" regardless of semantic, which ideally should
not be a puzzle as well. Code small things first and return early, same
as taking a test: do easy and quic
On Sun, 9 Oct 2022 at 16:05, Axy via Python-list wrote:
>
>
> On 09/10/2022 05:47, Chris Angelico wrote:
> > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
> > wrote:
> >> Got it, thanks!
> >>
> >> Actually the reason I never used "else&qu
On 09/10/2022 05:47, Chris Angelico wrote:
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list wrote:
Got it, thanks!
Actually the reason I never used "else" was the violation of the rule of
beauty "shortest block first". With if--else you can easily follow th
On Sun, 9 Oct 2022 at 15:39, Axy via Python-list wrote:
>
> Got it, thanks!
>
> Actually the reason I never used "else" was the violation of the rule of
> beauty "shortest block first". With if--else you can easily follow this
> rule by inverting "i
Got it, thanks!
Actually the reason I never used "else" was the violation of the rule of
beauty "shortest block first". With if--else you can easily follow this
rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest
On 10/7/22 21:32, Axy wrote:
So, seriously, why they needed else if the following pieces produce same
result? Does anyone know or remember their motivation?
In real scenarios there would be more logic in the for block that would
meet a condition and break out of the loop. If the condition
The else is executed if you don't "break" out of the loop early.
It cuts down on boolean flags.
On Fri, Oct 7, 2022 at 8:40 PM Axy via Python-list
wrote:
> Hi there,
>
> this is rather a philosophical question, but I assume I miss something.
> I don't remember I ever used
Hi there,
this is rather a philosophical question, but I assume I miss something.
I don't remember I ever used else clause for years I was with python and
my expectation was it executed only if the the main body was never run.
Ha-ha! I was caught by this mental trap.
So, seriously, why
1 - 100 of 1708 matches
Mail list logo
