It seems more succinct and cleaner to use:
if idx == 103: continue.
Of course this would be considered an anti-pattern, and Flake8 will complain. >Any opinions, or feedback on the matter.
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Of course this would be considered an anti-pattern, and Flake8 will complain.
Any opinions, or feedback on the matter.
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]> wrote:
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Of course this would be considered an anti-pattern, and Flake8 will complain.
Any opinions, or feedback on the matter.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Of course this would be considered an anti-pattern, and Flake8 will complain.
Any opinions, or feedback on the matter.
PEP-8, which is Guido's style guide and generally good to follow, does
not completely discourage single-line usage like the example. It's not
clear to me how Chris's example fits into the guidelines.
PEP-8:
"While sometimes it’s okay to put an if/for/while with a small body on
the same line, never do this for multi-clause statements.
...
# Wrong:
if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()
"
If the one-liner were not in a multi-statement block, it would be all
right with PEP-8.
I occasionally run across something like:complain.
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Of course this would be considered an anti-pattern, and Flake8 will
Any opinions, or feedback on the matter.
I personally tend to use
if test: return
even inside larger blocks.
I always try to avoid multiple returns from functions/methods, as soon
as things get complex it's all to easy to miss clean-up etc.
"No multiple returns" is often found in programming guidelines.
"No multiple returns" is often found in programming guidelines.
I religiously followed that when I did more C programming
than today. Then, I read an article about how the result
pattern makes functions measurably slower. (It should not
with an optimizing compiler, but it did due to those
measurements. Can't find that article now, though.)
I always try to avoid multiple returns from functions/methods, as soon
as things get complex it's all to easy to miss clean-up etc.
"No multiple returns" is often found in programming guidelines.
Multiple returns is not always a problem as it depends on the nature of a task whether it has complex enough cases.
I have seen code that instead sets Boolean variables when it is ready to return and everything else keeps checking the variables to skip further processing so the program then slides down to a single return statement. If done properly, it boils down to the same result if VERY carefully done but with lots of sometimes complex IF statements that may be not be updated well if the logic changes a bit.
In such cases, I vastly prefer clean and unambiguous returns from the function right at the point where the decision is made, UNLESS the exit is not always clean as there may be cleanup or finalization of some kind required that is best done at a single point.
If efficiency is an issue, then clearly a rapid exit may beat one where processing continues for a while and also often beats a method that involves creating and calling multiple smaller functions with lots of overhead.
Having said all that, of course, if you can find a fairly simple algorithm that only returns from one place, use it instead of a convoluted one. The issue is not necessarily that multiple return points are bad, but that they are often a symptom of sloppy planning. But for some problems, they fit well and simplify things.
-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=[email protected]> On Behalf Of Stefan Ram
Sent: Thursday, December 15, 2022 7:42 AM
To: [email protected]
Subject: Re: Single line if statement with a continue
Chris Green <[email protected]> writes:
I always try to avoid multiple returns from functions/methods, as soon
as things get complex it's all to easy to miss clean-up etc.
This "complexity" could also mean that the function has
become too large. In such a case, one could say that the
/size/ of the function is the actual cause of problems
and not multiple returns.
|Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
|Geniuses remove it.
Alan Perlis (1922/1990)
Within a small function, multiple returns are rarely
a problem.
When a function is large, one can apply well-known
refactors. For an example, look at the code in the
first post of the thread
Python script not letting go of files
Date: Tue, 29 Nov 2022 12:52:15 +0000
and then at my reply of
29 Nov 2022 14:44:39 GMT.
"No multiple returns" is often found in programming guidelines.
I religiously followed that when I did more C programming
than today. Then, I read an article about how the result
pattern makes functions measurably slower. (It should not
with an optimizing compiler, but it did due to those
measurements. Can't find that article now, though.)
"Result pattern" I call writing,
if a:
result = 123
else:
result = 456
return result
, instead of,
if a:
return 123
else
return 456
.
--
https://mail.python.org/mailman/listinfo/python-list
I always try to avoid multiple returns from functions/methods, as soon
as things get complex it's all to easy to miss clean-up etc.
"No multiple returns" is often found in programming guidelines.
A problem with having a single return is that it can lead to excessive >indentation:
if test_1:
...
if test_2:
...
if test_3:
...
return
Thomas Passin <[email protected]> wrote:
I personally tend to use
if test: return
even inside larger blocks.
I always try to avoid multiple returns from functions/methods, as soon
as things get complex it's all to easy to miss clean-up etc.
"No multiple returns" is often found in programming guidelines.
A problem with having a single return is that it can lead to excessive indentation:
if test_1:
...
if test_2:
...
if test_3:
...
return
With multiple returns, however:
if not test_1:
return
...
if not test_2:
return
...
if not test_3:
return
...
return
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]> wrote:I'm so glad that Chris and others say this. It (i.e. if plus break/continue/return on a single line) is something I have quite often
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
On 15/12/2022 04:35, Chris Angelico wrote:
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]>wrote:
I'm so glad that Chris and others say this. It (i.e. if plus break/continue/return on a single line) is something I have quite oftenI occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
done in my own code, albeit with a feeling of guilt that I was breaking
a Python taboo. Now I will do it with a clear conscience. 😁
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
On 15/12/2022 04:35, Chris Angelico wrote:
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]>I'm so glad that Chris and others say this. It (i.e. if plus break/continue/return on a single line) is something I have quite often
wrote:
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
done in my own code, albeit with a feeling of guilt that I was breaking
a Python taboo. Now I will do it with a clear conscience. 😁
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]> wrote:I'm so glad that Chris and others say this. It (i.e. if plus break/continue/return on a single line) is something I have quite often done in my own code, albeit with a feeling of guilt that I was breaking a Python taboo. Now I will do it with a clear
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
if 5 > 3: a = a * 3
b = b * 3
I happen to be of two schools here.prejudices of the one trying to make rules?
Is something sort of taboo when using something like a computer language to write a program? What if another language tells you to do it a different way or sort of the opposite? Is it based on the details of the language and implementation or the
If a compiler or interpreter HAPPILY (as happy as machines/code get) compiles or interprets your code without errors every time you use it a certain way, then it is not wrong to use it. Of course if it subject to change or already deprecated, ...
If people around you complain they do not like it, then the word "taboo" does apply but you can feel free to re-educate them or move on.phrase, or just a "noun" or just a "pronoun" or just a "nothing but an implied pronoun".
This reminds me too much of people who are taught some grammar such as some part of a sentence requiring a "noun-phrase" and later it explains that a non-phrase can be EITHER a noun accompanied by an assortment of other words that together form a
So which is it? The answer is all of them are legal, at least within bounds. A sentence like "Come over here" is an implied "You come over here" and works best if earlier sentences have laid some context on what is being talked about so the "you" isobvious or will be explained later but perhaps should be discouraged in other circumstances.
So back to computer languages. Many languages using grouping with something like "{...}" often do not care where you break your lines albeit some get touchy about an else statement placed improperly. It is perfectly legal to write:ONE. I mean it allows a simple expression on the same line after the colon and then terminates the construct so a future indented line is seen as an indentation error. An experiment shows the following attempt to line up a second line way over below the
If (condition) { first; second; third }
The grammar basically states that a "statement" or similar name can be a simple statement or a compound statement and anywhere one can go, within reason, so can the other.
Python has a twist here in that they discourage or outlaw some such things as they use mainly indentation rather than braces. This makes it hard to use multiple lines when the first line is way at the end as the others do not line up. It becomes all or
if 5 > 3: a = a * 3sense. I could imagine another design but since it is not what is done, the multi-line version MUST be done only on subsequent lines indented properly and identically.
b = b * 3
In a constant width font my second line is indented so "b is just below "a" and it fails because the interpreter does not measure the beginning column of the first line as being where the " a = a * 3" starts but at the "if" and that makes reasonable
So it is not really right or wrong to do one-liners. It is legal and often more readable. But if you ever want to extend your lines to be multi-line, it probably is best to use the multi-line approach regularly.whose short-term memory for many things is larger or smaller than mine. But generally people can handle simple constructs like we are discussing.
Still, using many editors, you will rapidly notice something is wrong when adding a line of code and seeing it is indented under the "if".
Is anyone really thrilled to read code in other languages that span so many lines:
If (condition)
{
var1 = 0
}
else
{
var1 = 1
}
It is a great way to get your line-of-code count up but the many briefer versions can be easier to read in one glance up to and including a bit murkier ones like
var1 = (condition) ? 0 : 1
My view is that simple things that fit easily on a screen, and also held all at once in my mind, should be written fairly concisely. I do admit how much I can hold at once varies based on how well I can concentrate at that moment and have met people
Complicated things and ones that might need changes later should be written very cautiously and in detail including judicious use of comments around and within the code OR consider re-planning it into a less complicated form that calls on other fairlysimple functions that can each be decently understood based on naming and usage.
If you have a complicated calculation that eventually assigns values to a1, a2, a3, a4 then a language like Python makes a
One liner easy as in:
If (condition):
a1, a2, a3, a4 = func(args)
But now that four or more lines have been collapsed into one, maybe something like this works too and maybe is a tad more readable with parentheses:
If (condition): (a1, a2, a3, a4) = func(args)
I am not suggesting using something silly like this though:
if(1): (a, b, c, d) = (min(1,2), (1+2)/2, (1*2*2*3)/4, max(1,2))
That is so way beyond a one liner that it is best seen as multiple lines. It may be legal but is best used to obfuscate!
The problem with some RULES is that not only are they not real rules but sometimes have exceptions where they get in the way of getting things done.
- Avi
-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=[email protected]> On Behalf Of Rob Cliffe via Python-list
Sent: Thursday, December 15, 2022 8:31 AM
To: [email protected]
Subject: Re: Single line if statement with a continue
On 15/12/2022 04:35, Chris Angelico wrote:conscience. 😁
On Thu, 15 Dec 2022 at 14:41, Aaron P <[email protected]> wrote: >>> I occasionally run across something like:I'm so glad that Chris and others say this. It (i.e. if plus break/continue/return on a single line) is something I have quite often done in my own code, albeit with a feeling of guilt that I was breaking a Python taboo. Now I will do it with a clear
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
It seems more succinct and cleaner to use:
if idx == 103: continue.
Nothing at all wrong with writing that on a single line. If you have
issues with Flake8 not accepting your choices, reconfigure Flake8 :)
ChrisA
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
If a compiler or interpreter HAPPILY (as happy as machines/code get) compiles or interprets your code without errors every time you use it a certain way, then it is not wrong to use it. Of course if it subject to change or already deprecated, ...
I occasionally run across something like:
for idx, thing in enumerate(things):
if idx == 103:
continue
do_something_with(thing)
for idx, thing in enumerate(things):For this example, I'd probably reverse the condition.
if idx == 103:
continue
do_something_with(thing)
if idx != 103:
do_something_with(thing)
Is something sort of taboo when using something like a computer language to write a program?
Dennis Lee Bieber <[email protected]> writes:
for idx, thing in enumerate(things):For this example, I'd probably reverse the condition.
if idx == 103:
continue
do_something_with(thing)
if idx != 103:
do_something_with(thing)
The first four lines of the quotation above cannot be a
complete program as "do_something_with" is not defined
therein, so they must be part of a larger program.
If, in this larger program, something still follows
"do_something_with(thing)" in the loop, the new program
after the transformation might not show the same behavior.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 19:44:15 |
| Calls: | 12,104 |
| Calls today: | 4 |
| Files: | 15,004 |
| Messages: | 6,518,093 |