Single line if statement with a continue

[Thomas Passin]

 >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.gross at 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.com at python.org> On Behalf Of Rob Cliffe via Python-list
> Sent: Thursday, December 15, 2022 8:31 AM
> To: python-list at 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 <transreductionist at 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
>