>if 5 > 3: a = a * 3
> b = b * 3
That would be a fairly weird construction, neither one thing nor
another. But still, if you really want it that way, this is legal Python:
a = 2; b = 10
if 5 > 3: a = a * 3;\
b = b * 3
print(a, b) # 6 30
On 12/17/2022 6:57 PM, avi.e.gr...@gmail.com wrote:
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, ...
That's not the point of using some consistent style. IMO, source code
should be clear, compact, and easy for someone else to understand. That
someone might be you six months from now.
These objectives do not always align. Consistency helps reduce mental
effort by using constructions and formatting in a familiar way -
basically, using a familiar programming idiom. Compactness can help
clarity, unless the code is too terse which can become a hindrance. But
too much verbosity can get in the way of grasping the essential processing.
Personal taste and familiarity also factor into assessing clarity and
compactness.
It's always a balancing act. Style guides can help by providing good
basic idioms. There's no law** that says you *have* to follow them
exactly all the time. But it's helpful when you can. If your own style
guide i is similar to one used widely, so much the better.
**Except at some organizations
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
