I happen to be of two schools here.
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 prejudices of the one trying to make rules?
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.
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 phrase, or just a "noun" or just a "pronoun" or just a
"nothing but an implied pronoun".
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" is obvious 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:
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 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 first also fails:
if 5 > 3: a = a * 3
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 sense. 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.
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.
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 whose short-term memory for many things is larger or smaller than
mine. But generally people can handle simple constructs like we are discussing.
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 fairly simple 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=gmail....@python.org> On
Behalf Of Rob Cliffe via Python-list
Sent: Thursday, December 15, 2022 8:31 AM
To: python-list@python.org
Subject: Re: Single line if statement with a continue
On 15/12/2022 04:35, Chris Angelico wrote:
> On Thu, 15 Dec 2022 at 14:41, Aaron P <transreduction...@gmail.com> 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
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 conscience. 😁
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
