New Ways to Be Told That Your Python Code Is Bad | Hacker News Reader

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

102 pointsnickdrozd249 comments

Ah, leave people alone.

I stopped using ternary expressions because someone told me not to. I could start using them again, whatever.

I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp).

For me, it's whatever I need to do to get through code review without arguing too much.

Don't add linter checks for these things, it's condescending.

At the very least, have the "greater good" on your side, e.g. "it confuses some people!" or "it is often a bug!" or "it can become a maintenance nightmare!" or whatever. If your reason is "I like it better this way," well then yeah, the reaction I would anticipate is "who asked you?"

The reason this bothers me isn't that I strongly disagree, but that I'm in the habit of doing whatever my linter tells me, and adding stuff like this cheapens the thing and makes it harder to sell to "I'm an expert, get off my lawn" people.

Why am I even writing this, I'm knee deep in C++ these days.

> For me, it's whatever I need to do to get through code review without arguing too much.

The language quibblers of the programming industry have installed a set of opinions, not knowledge.

They proceed to waste time and energy with their assertions.

> The language quibblers of the programming industry have installed a set of opinions

Pray they don't install another one.

This, really.

I'm most likely less experiment than some people here but after 10+ years of writing code, I came to the conclusion that the best code is the most readable code.

If all developers could write code that is easily readable for them (even after a few months break in the project), the software engineering world would be a lot better :)

Of course it makes sense to avoid anti-patterns and bottlenecks, but no much more really.

Readability is largely subjective. I think this sentiment is better described as optimising readability for the lowest common denominator in terms of both ability/experience and the most common style of code, that being imperative. That's not an unreasonable choice to make but there are other criterion by which to judge how easy or hard code is to read.

It comes up a lot in discussions about Go. A simple, "readable" language in which I can't tell you at a glance what a block of code does or is responsible for.

> For me, it's whatever I need to do to get through code review without arguing too much.

I agree with this. It takes a lot of context to truly understand another's code so reviews are just smoke & style checks, not real logic scrutiny like a kernel dev might do - in most cases businesses aren't willing to accept the true cost of such a review; I think the same is true of KT.

> Don't add linter checks for these things, it's condescending.

disagree. wrt pep-8 stuff, devs should be using their own linters before code is properly committed and for review. CI checks are easy to add and manage a quick/easy rebuke for the dev that doesn't bother.

For other style lints, tools that standardise trivial things (style w/ black, orderings w/ isort) reduce arguments and establish a consistent style. Code in whatever style you like, just standardise it for consumption. devs then argue at a higher level instead: over linter parameters.

> Don't add linter checks for these things, it's condescending.

Well as he states, these checks are not turned on by default. I have trouble seeing why someone who liked these extensions enough to turn them on manually would feel condescended to by them.

Fair point, I'm being defensive unnecessarily.

It still puts me off slightly that the tool mixes "make your code less prone to error" with "this guy wants this." Ok, live and let live.

I'm reminded of Douglas Crockfords's jslint, which is a mix of "this caused bugs before" with "how I write javascript."

I think the biggest proof that linting in general is not condescending against any one style is the frequent existence of multiple mutually exclusive linter checks, one for each style.

Consistent style is really nice.

I'm in the camp that "style" has very little real impact on readability, and linting for it mostly just creates friction. Maybe one time out of 100 I've got a weird case that truly needs to be indented differently, but my linter forbids it as dogma, so I either end up with code that's less readable or I add the noise of linter-disabling comments.

The things that really impact how understandable some code is have little to do with punctuation, or whether or not these two characters have a space in-between, or what type of quotes we use.

From the page:

> Generally speaking, less code is better than more code

This is true, but, generally speaking, readable code is better than compact code. Making it harder to scan through the code, or requiring more horizontal reading to understand code while you're scanning through it, is objectively bad.

This is going to push people towards making less-readable code for literally zero benefit. Considering how many of the checks in pylint are to make your code more readable, this is a clear step backwards.

I agree with him about the problems involved in while loops; there are cases where what you actually want is "loop forever until you die", but they are pretty rare, and all the rest can be converted into some other form of loop; that said, those situations also seem to more likely complicate the understanding of your code in many situations.

All in all, while-used is highly opinionated but has a point to make; consider-ternary-expression is an asinine addition that's going to push people towards writing objectively worse code for literally no benefit other than reducing line count. If that's your KPI, then sure, fill your boots, but it makes zero sense to enable it by default.

Edit: To clarify, it does not seem as though PyLint is enabling this by default, but I'm concerned that some shops will enable it by default and push their developers to write worse code.

This is why I only ever run PyLint with the -E option, which makes it focus on diagnosing actual bugs.

I am concerned about the trend in Python open-source projects to consider any deviation from their machine-checked coding style a bug. There's pylint and pep8 and isort and 'black' - the list grows ever longer.

I kinda like it when people yell at me for submitting a patch without tests. Having quality standards is great. I like it a lot less when some CI machine yells at me for failing to put the "correct" number of blanks lines between methods.

> For me, it's whatever I need to do to get through code review without arguing too much.

This seems like a horrible attitude, if everyone did this codebase will go downhill really fast. Sometimes you have to use better/new practices and successfully advocate for them in code review.

> Don't add linter checks for these things, it's condescending.

Automated standardized checks are "condescending"?

> but that I'm in the habit of doing whatever my linter tells me

Sounds like you need to improve your lint checks. You _should_ usually be accepting the vast majority of lint auto fixes.

> Python programmers in general have an irrational aversion to if-expressions, a.k.a. the “ternary” operator.

Because the Python ternary operator is fucking backwards! Why on earth would you put the condition in the middle!?

  x = 4 if condition() else 5

vs.:

  condition() ? 4 : 5

vs. the author's own lisp example:

  (setq x (if (condition) 4 5))

I love ternary operators, and Lisp/ML-style if else blocks that return things, but Python puts the 4 and the 5 so far away from each other that even I hate using it, especially when condition is a chained mess rather than just a function call.

In practice it's not that bad. One bad thing is you can't write long chains as you can do with C-style ternary operator.

That's not a bad thing, long ternary chains are illegible. You should never have more than one condition in a ternary.

There are some specific shapes of chained ?: that are fairly legible. Eg

    c = condA ? valA :
        condB ? valB :
        defaultVal;

For Turing's sake, if you insist on chaining ternary operators, then you should always use parens instead of showboating that you cleverly-by-half memorized a particular language's obscure precedence and associativity rules.

PHP in all its glory and splendor actually originally used left-to-right instead of right-to-left associativity for the ternary ?: operator, so that expression you wrote works differently in PHP and (JavaScript or C or any other language). (Side note: notice how I used parens instead of depending on you guessing about the relative precedence of "and" and "or" in English.)

It's easy (and perfectly valid) to blame the designers of PHP for not knowing or caring or paying much attention to the syntax of the programming languages they were imitating, and doing something that stunningly stupid, but it just goes to prove that many people (especially PHP designers like Rasmus "I don't care about this crap at all" Lerdorf and typical PHP programmers) don't even have the faintest idea what the precedence and associativity of many of their favorite programming language's operators are, or what those terms even mean, and they just willy nilly cargo cult copy and paste and translate between PHP and JavaScript code examples from Stackoverflow, introducing terrible hard-to-spot bugs.

https://en.wikiquote.org/wiki/Rasmus_Lerdorf

>"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf

But the real fault lies not just with PHP for parroting C incorrectly, but with C for doing something that stupid and hard to remember and easy to get wrong in the first place.

Please always use parens for that kind of stuff, because even if YOU memorized and love to depend on and show off your knowledge of the precedence and associativity rules of the language you're using, the people reading and modifying and maintaining your code probably don't.

https://wiki.php.net/rfc/ternary_associativity

>PHP RFC: Deprecate left-associative ternary operator

>Unlike most (all?) other languages, the ternary operator in PHP is left-associative rather than right-associative. The left-associative behavior is generally not useful and confusing for programmers who switch between different languages. This RFC proposes to deprecate and remove left-associativity for the ternary operator and require explicit use of parentheses instead.

>As an example, the code

    return $a == 1 ? 'one'
         : $a == 2 ? 'two'
         : $a == 3 ? 'three'
         : $a == 4 ? 'four'
                   : 'other';

>would in most (all?) other languages be interpreted as

    return $a == 1 ? 'one'
        : ($a == 2 ? 'two'
        : ($a == 3 ? 'three'
        : ($a == 4 ? 'four'
                   : 'other')));

>which is both the useful and intuitive interpretation. In PHP, it is instead interpreted as

    return ((($a == 1 ? 'one'
           : $a == 2) ? 'two'
           : $a == 3) ? 'three'
           : $a == 4) ? 'four'
                      : 'other';

>which is generally not what was intended.

https://stackoverflow.com/questions/20559150/ternary-operato...

>Q: Can someone please explain what is happening here and why it is printing 'four'?

>A: Because your whole expression evaluates as if it was (......) ? 'four' : 'other'. Since the first element is probably something truthy, it gives you 'four'. In saner languages, where ?: has right associativity, the whole expression evaluates as if it was $a == 1 ? 'one' : (......), where if $a is not 1, you go on to test other things.

http://phpsadness.com/sad/30

>PHP Sadness: Ternary operator associativity

>The ternary operator is left-associative and therefore behaves entirely incorrectly:

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

>PHP: a fractal of bad design

>Unlike (literally!) every other language with a similar operator, ?: is left associative.

Still beats APL

No, consistency within a language is good!

https://en.wikipedia.org/wiki/APL_(programming_language)#Des...

>All primitives are defined to have the same precedence, and always associate to the right. Thus, APL is read or best understood from right-to-left.

But consistency across all languages is too much to ask for, except when one language is purposefully imitating another language's syntax but subtly changing it, like PHP did to C. Or the way Perl and PHP imitated C's syntax for references with &, implying that they were somehow alike and could be used in similar ways, even though they're totally different foot guns.

At least APL and FORTH and LISP pick a lane (albeit different sides of the road), and stay in it.

As PHP’s RFC says, right-associative ternary is useful and intuitive. I don’t need no parentheses, the meaning is clear and obvious and doesn’t go wrong in any environment that I or those I work with use, and doesn’t even go wrong in PHP any more (warning in 7.4, syntax error in 8). I’m not going to compromise the beauty and editability of my code by inserting superfluous parentheses—they’d make me have to think more about the meaning of the ternary chain, not less.

I don't think it's backwards, it's just different than C and derivatives, and makes different things simple. I quite like the

  x = ( 1/y if y > 0 else
       -1/y if y < 0 else
       nan())

idiom.

Thank you! For years I've tried to figure out how to chain the Python ternary operator while maintaining readability, and here it is!

> Why on earth would you put the condition in the middle!?

For readability.

Because that's what Guido liked, that's the answer.

I don't like it much, but it's neat that the "happy" path value is a prefix of the assignment statement, i.e. in

    x = 4 if thing() else -1

there is a prefix

    x = 4

which, if the predicate is "expected," is like saying

    x = value (... unless blah blah)

which, I could see some people liking (maybe Dutch people).

Let's just write everything in Scheme for God's sake JOIN US.

> which, if the predicate is "expected," is like saying

> x = value (... unless blah blah)

Except it's the opposite of that, because "if" is the opposite of "unless". It's more like saying

    x = value (... if blah blah)

Good point. The "blah blah" in my case would have to negate the condition.

    x = value (... unless this isn't true, then it's blah instead)

The stuff in parentheses is a caveat. Works just as well your way, and more directly.

    x = value (... so long as this is true, otherwise blah)

I’ll give a shot at answering your rant with another one:

I’ve never figured out those question marks. And in your example, what the hell even happens if condition is true or false? At least the lisp version has a function call that includes the word set, so you can kinda guess that the x variable is set.

The if-expression reads very close to English, so you don’t need to look it up in the manual to read it.

I wouldn’t even know what to query to look up `code ? Code : code` in a manual / google. `setq` is also easy to look up.

The question mark colon loses on all counts in my book. I hate it.

The C example doesn't match the others as the assignment is missing.

It should be:

  x = condition() ? 4 : 5

I love the Python version, it reads like English.

Use umbrella if raining, else wear shades.

Do you mean "use(raining ? umbrella : wear(shades))" or "raining ? use(umbrella) : wear(shades)"?

Personally I prefer FORTH, which like Yoda reads, and unambiguously puts the condition first, the IF second, the ELSE third, and the THEN last.

    FORTH ?KNOW IF
      HONK!
    ELSE
      FORTH LEARN!
    THEN

FORTH doesn't have expressions, parens, precedence, or associativity rules, it just has a stack (or rather, two stacks: operand and return; or three of you count the vocabulary search stack). ( And actually it does have parens, but they are for comments! )

Is this how you would say it in English though? I think "If raining use umbrella else wear shades" is closer to regular English.

It's closer to Python too, other guy messed up the example

I thought in Python it was:

    thing_to_take = umbrella if raining else shades

while in OCaml/English it would be:

    thing_to_take = if raining then umbrella else shades

If you don't like awkward ugly clunky syntax, you probably shouldn't program in Python. And, for that matter, if you like correctness checking, you also shouldn't program in Python...

Serious question, what alternative(s) to Python would you recommend with nicer syntax?

Scheme or Go.

Well, to be fair, sometimes, especially for short scripts, you're stuck with Python because you know it's going to be available.

Personally, from a syntax point of view, as opposed to an easy availability point of view, I prefer Haskell, or Lisp if you can live with the parentheses. Haskell has some syntactic oddities, and the support for infix operators has encouraged the ecosystem to define way too many obscure </?$+/>-looking things, but the syntax mostly just gets out of your way and is relatively regular.

I do admit that if you're going to be infixy anyway, a C-like "?:" ternary is nice. C got its expressions right.

It is, of course, objectively true that one of the things Python does get right about syntax is the significant whitespace, and Haskell has that too (without the stupid colons). Curly braces are the work of the Devil, and "BEGIN" and "END" are just unmentionable.

I don't think Python gets semantic whitespace right. It requires extraneous parenthesis and has an impact on lambda functions, making them way less powerful than they should be.

Haskell got it right.

Ruby for me. I program in both, primarily Ruby with a few python microservices and Ruby’s syntax is similar to Python in a lot of cases but much easier and nicer to break out for something “nicer” to look at. All in my opinion of course.

Honestly, I've been positively surprised by F#. Nice syntax, functional-first, pragmatic design.

For web stuff: JavaScript

For data science stuff: Julia

I prefer perl's style, which IIRC is also in ruby and coffeescript:

    x = 5
    x = 4 if condition()

Ruby also has a C-like ternary operator. Many options for people that prefer them :)

I think the Python ternary is best read as "DEFAULT_VALUE if COMMON_CASE else FALLBACK", and is best used in situations where this is what is meant semantically. If you're dealing with two equally plausible code paths, the standard if/else branching structure makes that more clear.

This is how I use it. If I want an empty list as a default argument for some function, I do something like this:

    def foo(things: Optional[List[str]] = None) -> None:
        thing_list = things if things else []
        ...

I prefer this Python syntax:

    x = condition() and 4 or 5

If you know the first value is truthy, sure.

  x = condition() and [] or True

is not equivalent to

  x = [] if condition() else True

Now, I have seen a genuine application of `X and A or B` before. That occurs when you're checking a condition before, say, popping from a list -- but if the list is empty, you still want a default value.

Can you give me an example where the two return different values?

When condition() is truthy, the first evaluates to True and the second evaluates to []

Try it out. https://ideone.com/GciAs8

So the problem is not in condition() but in the the other statement/expression. Similarly,

    True and False or 5

returns 5 rather than False.

I love Python but my personal hate goes for this when used in list comprehensions.

    a = [1,2,3]
    # list comprehension with if
    [ x for x in a if x > 1]
    [2, 3]
    # list comprehension with if/else
    [ x if x > 1 else x*2 for x in a]
    [2, 2, 3]

When it's just "if" it goes after the "for", when it's "if/else" it goes, all of it, before. I still don't understand why it's this way, it doesn't even make sense even reading it in natural language. I much prefer the mathematical-like syntax present in Scala for this.

Edit: Thanks for the responses, they are are insightful, never thought of this that way.

Still in my head the lack of "else" clause implies filtering no matter where, while its presence implies transformation no matter where. The first element of the list is always transformed (though in this example it's identity).

I think it's a case of Python trying to do too much with too little. Personally for anything relatively complicated I still prefer to use filter() and map() as list comprehensions can get unwieldly quick.

The "before" is what value is returned, the "after" is whether it should be returned.

In your case you were conditionally choosing a manipulated return value for x and didn't care at all about filtering the list. Here's one with both:

  [x if x > y else x*2 for x in a if x % 2 == 0]
   ^^^^^^^^^^^^^^^^^^^            ^^^^^^^^^^^^^
   return x as...                 filter down to only...
   x or x*2                       even 'x's

There's not really a semantically logical place for an "else" in the latter half because it's only looking for a true statement so it can return x (or not).

For example this makes sense:

  ... if x % 2 == 0 or x == 3

(filter the list to even values of x or the value 3)

but this does not:

  ... if x % 2 == 0 else x == 3

(filter the list to even values, otherwise wait, otherwise?)

The point is not that we're idiots who don't know the language, but that functional-style ordering does not align with human cognitive cues.

The problem is that functional-style fails to separate essential bits and fails to give strong visual clues where each bits begins and ends.

That is why the old imperative style is clearer. Compare:

    for i in container:
        do something with i

and

    [do something with i for i in container]

One has a clear separation of loop and action, the other requires scanning for the "for i" in the middle. This generalize to other similar construct, and the Python ternary operator has the same flaw. The imperative if / else version clearly separate alternatives on separate lines.

IMO, syntax design should always try to learn from the imperative style and always strive to produce a syntax that clearly separate each logical item in a compound statement, and using different lines is one of the best for us human to visually grok.

(That's why even Lisper will often format their code to separate bits on different lines!)

Don't be a jerk.

OP clearly stated he didn't understand it:

> When it's just "if" it goes after the "for", when it's "if/else" it goes, all of it, before. I still don't understand why it's this way

and discussing it here on HN shouldn't be punished.

...

Back to the topic at hand ...

List comprehensions save you enough syntax to be worth it, IMHO:

   mylist=[]
   for i in container:
      if i > 10:
          mylist.append(i*2)

   mylist = [x*2 for x in container if x > 10]

... That's a very terse, clean request for work and arguably it's easier to read than "for(int i=0; i<10; i++)", which we've all acclimated to by the end of CS101. I think they're quite worth the trade-off.

The first is a transform of the values (with only that, the list stays the same length, the IF says whether the transform happens or doesn't for each value), the second is a WHERE filter picking or dropping some values (list might shrink), you can have both (list shrinks and the selected values are transformed):

    >>> list([ x if x > 1 else x*2 for x in a if x <3] )
    [2, 4]

> but my personal hate goes for this when used in list comprehensions.

I feel you. I still use them though because they are still more readable then alternatives.

As I recall, object? and object?? are and work in IPython because the Python mailing list said that the ternary operator was not reserved. (IIRC there was yet no formal grammar or collections.abc or maybe even datetime or json yet at the time).

Ternary expressions on one line require branch coverage to be enabled in your e.g. pytest; otherwise it'll look like the whole line is covered by tests when each branch on said line hasn't actually been tested.

  .get() -> Union[None, T]

I really hope that the condescending tone of the article was because the author was tired or something, and that it's not the attitude they use when contributing to a linter. The authors comes out as arrogant and self-centered, the "reactions" are strawmans, the tone is aggressive.

Sure that nice Beeping Busy Beaver uses only one loop, very cool. The "guessing game" program that almost everyone wrote when learning programming also uses one loop.

I'll now go work on my linter for blog posts that forbids using bold text. The Bible didn't use any bold text, so why would a simple blog post need it?

> The "guessing game" program that almost everyone wrote when learning programming also uses one loop.

Just because it’s used by very beginners it doesn’t mean it’s good. That’s, like, the opposite of the truth. Beginners also clutter their code with endless “else if” sequences.

You just complained about strawmans and followed with a strawman.

> Just because it’s used by very beginners it doesn’t mean it’s good. That’s, like, the opposite of the truth.

I don't remember saying anywhere that this guessing game was good. You're putting words into my mouth (keyboard?) here. What I meant to say was that saying that the Beeping Busy Beaver only needs one loop doesn't add anything to the discussion, since a simple guessing game also needs one loop. Quoting the article:

> If you have a while loop and you are not working on something that requires unbounded computation, chances are that it can be rewritten more clearly as a for loop. I ran this check against the Pylint codebase itself, and I was shocked by the hideousness of some of the while’s that turned up. They couldn’t all be rewritten, but many could.

> Even the recently-discovered Beeping Busy Beaver champion program only uses one unbounded while loop, and that’s as a kind of toplevel program driver.

Here's how I would put it, in a kinder and more humble way:

"Most of the code I write only needs one main loop, and usually I'm not the one writing it. When I'm using something like Django, I have no need for a while loop, as it's already handled by the framework. In that case, I want the linter to highlight these loops. They are a potential danger, and something I want to pay special attention to. Even when I have to write myself that loop, I want to clearly separate the main loop from what runs into it. In my experience, this leads to code that is more readable, more maintanable, and that has less bugs. Thus, this is a good linter rule."

> Beginners also clutter their code with endless “else if” sequences.

Well, it's not like they can use a switch, considering it's Python. Or are you referring to pattern matching? Or you think using a dictionnary would be more idiomatic? I'm not sure what you're trying to say here.

The part about the Bible and bold text was a parody of the article to quickly highlight what's wrong with it. I personally dislike bold text. I think people shouldn't use it most of the time. Thus I did the same thing as in the article: I used an appeal to authority (the Bible, equivalent to the Beeping Busy Beaver) to say that everything smaller than the Bible shouldn't even use bold text, as the Bible doesn't need any.

Maybe the tone is fully representative. One could start to wonder what kind of people would be attracted to working on linters. 'Now I get to tell everybody what is good or bad'.

I don't think we should extrapolate to what kind of people work on linters or even on how the author thinks. I think the article and the contributions both come from good intentions, and I even agree with the two linting rules. What I don't like at all is the tone of the article. Part of the role of linters is education, and education shouldn't be done with that tone.

> forbids using bold text

Hah. Once-upon a time, I relied on bold text a lot for emphasis. Then I learned that its a crutch for bad writing, so I made an effort to use it very sparingly. I think my written material has improved substantially because of it. I think keeping bold text to a minimum is a good rule to follow when writing.

> Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way.

The nice thing about ternaries is that they're expressions, so they don't "infect" our code like statements (e.g. 'if'). For example:

    if xCond:
      x = x1
    else:
      x = x2
    if yCond:
      y = y1
    else:
      y = y2
    if zCond:
      z = z1
    else:
      z = z2
    foo(x, y, z)

This lint rule will tell us to do the following instead:

    x = x1 if xCond else x2
    y = y1 if yCond else y2
    z = z1 if zCond else z2
    foo(x, y, z)

Now that our branching is done with expressions rather than statements, we can actually in-line them, which seems much nicer (less chance to get them mixed up; no need to invent new names; no side-effects, e.g. accidentally overwriting an existing variable; etc.)

    foo(
      x1 if xCond else x2,
      y1 if yCond else y2,
      z1 if zCond else z2,
    )

If we really want the names, we could define them using the 'walrus operator':

    foo(
      x := (x1 if xCond else x2),
      y := (y1 if yCond else y2),
      z := (z1 if zCond else z2),
    )

Personally I would use separate 'x = ...' statements rather than :=, since we want to explicitly perform effects (binding names).

You don't need the walrus operator, as keyword args are valid.

    f(x=a if b else c)

Should be valid. All the walrus gets you is making the x "infect" the surrounding namespace which is surprising.

Except it's different semantics. The example with 'foo' and the walrus operator doesn't even use keyword arguments, and the keyword arguments may not even be valid, depending on the definition of 'foo'.

> All the walrus gets you is making the x "infect" the surrounding namespace which is surprising.

Yes, that's what I intended. I was pointing out that the foo(x1 if ...) version does not behave the same as the separate 'x = ...' statements, since it doesn't bind the x/y/z variables.

This is usually an advantage (if we don't need those values for anything else), but for completeness I noted that we could use the walrus to recreate the exact behaviour (keyword arguments can't do it, since they only bind variables inside the function call, which (usually) has no observable difference to using positional arguments). You're right that the walrus's effect on the surrounding namespace is 'surprising', and that's why I would prefer to use separate statements if we really want those names defined (since that's less surprising).

I think I might be in the minority here that I prefer the fully laid out statements.

Sure in small cases this small ternary use is great! However too many times I've seen people chain them for far too many characters just to be "on one line".

We don't use one letter variable names anymore, so in the same reasoning why should we do the same to our code?

Yup; the booleans are difficult enough from a logic point of view, don't need to make it more complicated by using syntactic sugar.

I strongly disagree with the author's idea that shorter is better. Clarity trumps conciseness. I'll admit that not enough conciseness can impact clarity, but there's ways and means to clean that up that don't involve clever code.

I hypothesise that the actual meaning (possibly subconscious) underlying those uses of "complicated", "syntactic sugar", and "clever code" is 'not the way I'd write it'; and that "clarity" and "clean" actually mean 'the way I would write it'.

To test whether those statements are guiding principles, or merely ad-hoc justifications, I propose the following pylint rules based on those principles:

    no-ternary-sugar:

      Replace 'x if y else z' with '{True: lambda: x, False: lambda: z}[y]()'.
      This is less concise, but improves clarity by using booleans explicitly,
      and making the delayed evaluation of the results clear; both of which are
      implicit in the 'if/else' syntactic sugar.

    no-elif-sugar:

      Replace:

        if foo:
          bar
        elif baz:
          quux
        ...
        else:
          foobar

      With:

        if foo:
          bar
        else:
          if baz:
            quux
          else:
            ...
            else:
              foobar

      This is less concise, but makes the branching structure clear, unlike the misleading
      "flat" appearance of the 'elif' syntactic sugar.

    no-special-case-patterns:

      Replace:

        if foo:
          bar
        else:
          baz

      With:

        match foo:
          case True:
            bar
          case False:
            baz

      'if/else' is syntactic sugar for pattern-matching a boolean, which is left implicit.
      Explicit matching improves consistency with other use-cases, and makes the relationship
      between branches and boolean clear, at the expense of conciseness.
      (Also applies to single-armed 'if', which will only have a 'case True:').

Of course, the combination of no-elif-sugar and no-special-case-patterns would give extreme clarity like this:

    match foo:
      case True:
        bar
      case False:
        match baz:
          case True:
            quux
          case False:
            ...
              case False:
                foobar

I personally would have wrote the first one as a first pass, mostly so I could probably at some point put break points on what is going on. Then probably called it 'done'. I had actually forgot you could even do this thing in python. The highest complement I get from other programmers is 'your code is easy to read'.

Everyone has their own 'style' they like. It is usually not that big of a deal. It becomes a big deal if you get someone on the team who becomes obsessed with it, or someone who is always sloppy. Compact styles tend to be harder to decipher than simple ones. As when you are reading them they usually are not the same style context as all the other code around it. So it causes your brain to have to stop and figure it out. With python sometimes those compact styles actually run faster, so they can be handy to know about (test it though).

In java there is this thing where many will do things like blah = x().y().z(); Yet at any point in that chain something could crash out and return a null. It is compact for sure. But really is a pain to debug, but easy to read. Yet a lot of what is going on is burred in the 'middle' what if something in the middle is returning the wrong thing and the next thing in the chain happens to have the right method?

Compact styles can be easy to read sometimes if you know what that style is. You can also very easily introduce very subtle bugs. You can also convey the wrong meaning to the next poor soul that has to look at your code 3 years from now, 2 years after you left the company.

I use this style as sparingly as possible and fall towards verbose and spaced out code. I try to make it easy to read and broken down as best as possible. 6 months from now my tired brain will thank me.

For something like this example if I ended up with an if tree like that I would look at the underlying data structures. There is a data problem here and there probably would be a better way to do it.

I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc.

I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html

tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreading logic over many lines can lose abstraction; we can end up lost in a tangle of bools, ints, etc. without seeing the bigger picture.

Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended up with one of those 'clever' bits of code. It was the best solution because of the constraint we were in. But a co-worker (who helped create it) put it best 'no damn way are any of us going to be able to figure that out 6 months from now'. He was perfectly right, and it did take me 2 days to untangle it about a year later. That was comment time to for future me to put in what was this thing doing and why it worked the way it did (lesson learned).

Getting that 'terse'/'readable' balance right can be tricky. Usually if some code is 'hard to read' it usually means it needs a bit of refactoring to shorten/length it up and make clear (with comments) what each bit is doing. You go drop something like duffs device into the middle of a parser you should put a comment on that. As not everyone has heard of it. If the code is going to be used a couple of times a year and if it takes an extra 15 seconds, so what. Comment it with 'hey this would be a good spot for duffs device?'. Most of the type of code I write these days runs so rarely and can take a bit of extra time. I am also working with jr devs who may or may not have read up on every cool trick. I am also playing with some code I got from the net. Some of these things have 5 page long functions, yep... totally lost in abstraction.

An ideal that you want to try to attempt to work through is the Principle of Least Power[0].

While is strictly more powerful than for, for is strictly more powerful than foreach, foreach is strictly more powerful than map.

And yet 95% of the time, the power in map is sufficient. Therefore 95% of the time you should use map. When you encounter a foreach, you should be expecting non-purity. When you encounter a while, you know that it's doing some recursive operation that requires that power. If you have junior members of the team writing while loops where maps would do the senior members of the team who understand the nuance will take 10x more time to understand that code.

The same applies to statements/code blocks vs expressions. If all you are doing is assigning one value and have no other side effects, and you can do so in a way that's not overly nested, you should use an expression. If you can't, we have the more powerful statement/block structure to fall back on.

[0]: https://blog.codinghorror.com/the-principle-of-least-power/

Thank you for that link. I'd not seen it before but after reading the W3 article on it I wholeheartedly agree with it!

It was interesting to find out how HTML was designed from the start to be simple and not a programming language on purpose for this reason!

I have problem with both new checkers:

regarding the `consider-ternary-expression`

    if condition():
       x = 4
    else:
       x = 5

allow me to put fck'n breakpoints - in this case the expression is dumb, but what if is some complex stuff?
x = 4 if condition() else 5
is cute, but - remember, kids - not everything* should be an expression

regarding the `while-used`, while I personally prefer the legibility of the `for` loop, I find the following paragraph... at best wrong:

>>> A while loop introduces unbounded computation. Do you really need unbounded computation for your boring web app? I doubt it. In almost all cases, the loop can be bounded in advance, as in “do this N times” or “do this for every item in this list”. Those kinds of loops are guaranteed to terminate, and that’s a nice guarantee to have.

in python `for` loop are equally unbounded as `while` ones. Yes, most of the time you are looping over a (finite) list or a (finite) dict, but the concept underlying the `for` loop is the iterator, not the list. And iterators can easily be infinite.

> in python `for` loop are equally unbounded as `while` ones. Yes, most of the time you are looping over a (finite) list or a (finite) dict, but the concept underlying the `for` loop is the iterator, not the list. And iterators can easily be infinite.

Not only iterators, but also plain lists. Example:

  a=[1]
  for i in a:
    a.append("the ride never ends")
    print(i)

Did you try that out in a REPL before posting? You should.

I'm guessing he did, because it does exactly what he's implying it does.

wow, my bad. That's sets & dicts that invalidate their iterators when the size changes.

Iterating over mutable unordered containers is an entire new level of crazy.

That's what linters are for, right? To make your code more fun to read

> less code is better than more code

Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity:

> x = 4 if condition() else 5

Exactly. I pretty much love everything about Python except its ternary operator. I also prefer C’s.

When I first started using python, I assumed it had a normal (c-like) ternary operator and was a little surprised to discover the syntax we're talking about. But after some time, it actually feels very natural to me, and is arguably more intuitive than ?: syntax. I assume this is where the author is coming from.

Arguably? It can be read like a sentence. ;-)

I assume they're talking about the meaning, not how you spell it.

So you can read both as a sentence. The arguable part is more about "condition and then thing" versus "thing if condition".

Exactly. I prefer this a lot more to at least avoid using else:

  x = 5
  if condition():
      x = 4

No, that's not good. If condition() is true, x shouldn't take the value 5, even temporarily. The combination of

  (x = 5, condition())

is inconsistent state (using the word "consistent" in the same sense as the C in ACID).

It really is clearest and safest to avoid inconsistent state, even if is only transient. There are so many ways programs can be wrong; no need to deliberately create inconsistent state when there's no need to.

In your version, we need to check the definition of 'condition', to see whether the 'x = 5' statement has any affects on its execution. The ternary won't assign the variable until we know its value.

Also, your version isn't safe to use with objects (e.g. 'myObject.x = ...'), since the initial assignment could trigger arbitrary code (properties, __setattr__, etc.).

Also, your version isn't safe to use when the right-hand-side has effects, e.g.

    x = fetch_config_url() if remote else read_config_file()

Can't be used in list comprehension either

My favorite way to write that is with expression oriented langauges. Example in OCaml:

    x = if condition() then 5 else 4

I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.

Yeah, Python's willingness to break up conceptual concepts into separate parts of an expression such that you might need to backtrack while reading has always seemed an odd choice to me, exemplified by list comprehensions, especially when nested.

It is simply a design choice, the common value is given first. Comprehensions in Py are the same.

Sure it's a design choice but, quoting the Zen of Python:

> Special cases aren't special enough to break the rules.

> There should be one-- and preferably only one --obvious way to do it.

Both are broken by the existance of 2 if syntaxes depending on the context.

But when you write "condition ? first : second" or "(if condition first second)", the first common value is still given before the second uncommon value, so what's the advantage of putting the condition BETWEEN first and second, instead of BEFORE? After all, the condition has to be EVALUATED first before deciding which one to use.

Infix "if" conditions just scramble up the order of evaluation from the order of program source code.

The argument is that the most common value should be first and the rest can be thought of as rare and almost ignored. I don’t always agree, but still prefer it to C syntax which I have to look up every time.

To add to the cacaphony of counterarguments to this, this can introduce nonobvious bugs when refactoring.

If the condition-guarded statement is nontrivial and you remove the assignment, everything stays valid. If otoh you use a ternary or

    if x:
        y = 1
    else:
        y = 2

If you now delete the else block or something (like the assignment from a larger else block), a linter can warn you that y is undefined. Otherwise you'd need a test to ensure correctness.

I don’t think this criticism is valid for Python specifically where the most Pythonic expressions, generators of all forms, are read front to back like this.

    [ x.attr for x in list if x in someset]

There are languages where this kind of thing would be considered ugly and you’re supposed to use map/filter but in Python they’re the best practice. Every Python programmer is already trained to read expressions like this.

Helper variables have a serious place in growth phase, when you typically have lots of new devs and lots of bad code.

$user_authenticated = hmac_auth($_get['token']) === true || ldap_check($username, $config['ldap_restrictions']) || verify_credentials($_post['user'], $_post['pass']) === true;

Sorry for the php pseudo code, I'm on mobile. And this is a very friendly example of what I'm trying to get across. It's self documenting code and worth the extra bytes.

I've seen way too many insane conditionals to agree that less code is better.

I'm really not seeing what's illegible about this?

For the cost of 4 extra characters, this line tells you exactly what it does even if you've never seen Python in your life.

Reversing direction is annoying to suddenly have to.

Yeah I don't like them as implemented, because most of my 'if' statements are in response to unforeseen things, so my mental expansion of it is 'Now, stop and check if...'

I wouldn't mind it so much if I could write it as:

  x = 4 unless shenanigans(); then x = 5

Yes, that is a semicolon. Fight me.

That's PERL right there.

Makes way more sense to my brain to read:

print unless $x ~ /end$/;

then

print if $x !~ /end$/;

I used to get flack for using not just if expressions as ternaries, but also for using unless. Then I started teaching PERL at my company and drilled it into all the fresh new minds.

I gotta be honest and say I like Python because it only has a limited amount of punctuation.

Also worth remembering that a perl statement can be converted into an expression with a do block, so you can write

    my $x = do {
      if (foo()) {
        4
      } else {
        5
      }
    };

(and yes, I know, that example would look fine as a ternary - but this is meant to illustrate the syntax possibility, not where I'd specifically use it - and once the logic within one of the two conditional branches gets more complicated, switching to do+if+else can make for clearer code)

I had a good chuckle as while reading this comment I was thinking "oh, I saw code like that just last week while reading SQL::Abstract's source", and then I saw the username. :)

Guilty as charged :D

What the... ? Why is that worth remembering? Just reading that code makes me feel dirty, let alone deploying it! ;-)

Sometimes the logic in at least one of the arms of the if/else is sufficiently complicated to make it worthwhile (e.g. cases where you find yourself needing a 'do' block inside a ternary).

Also doing that with if/elsif/elsif/else is often far more readable than nested/chained ternaries.

What's so monstrous about it? It's practically English:

    cssClass = 'selected' if isCurrentTab else 'deselected'

Probably b/c Python abuses the same keywords way too much. (But that shouldn't be such a surprise already to oppose this particular case.)

You have a weird perception of English. "If the tab is selected, the CSS class is 'selected', else it's deselected.

Or in pseudocode

    if isCurrentTab
      cssClass = 'selected'
    else
      cssClass = 'deselected'

Even ternaries read weird. "css class is current tab HUH?? selected COLON! deselected"

“Set css class to ‘selected’ if it’s the current tab, or else ‘deselected’.”

Both read grammatically fine to me. If you prefer to do things in 4 lines rather than one, and repeat the variable, that's up to you I guess - a lot of people seem to agree - but honestly I don't get what the fuss is about.

If a one liner is preferred, what if it could be:

if condition(): x=4 else: x=5

Agreed - relatedly, I really dislike one-liners in code because more often than not, it's done for the sake of being "clever" rather than having readable code for the next person to quickly skim and understand.

I get that it's a "flex" or some sort, but honestly in production code my experience is that it reduces productivity. Programmers need a little more squinting to truly understand what that piece of code is doing.

I find it similar to run-on sentences in books - we don't like that, and in Business Writing courses they explicitly say to not do that. Code should be similarly readable.

> I really dislike one-liners in code

So...you should do more per line, since code is all one-liners, its just a choice of how many, so if you don't like them, you should reduce the number?

Honestly, the Python version is far more readable to me than the C, and that's even with close to a decade with C before encountering Python or any other language using that style.

Though Ruby’s unless modifier is often slightly better for readability.

In C, I always put the ternary clauses on their own lines prefixed with the operator. This always makes things readable.

    int result = condition
        ? value * 12
        : something_else();

and in the case where the condition is sufficiently complex:

    int result =
        (
            some_condition()
            && another_condition()
            && yet_another_condition()
        )
        ? value * 12
        : something_else();

For me, at least, this is entirely readable. The unfortunate bit is that there is no formatter in existence (yet) that can handle this for C, or really any other language with similar syntax.

Python's "Black" formatter actually does the best job here, yet the python ternary syntax is still very verbose and strange IMO.

> The unfortunate bit is that there is no formatter in existence (yet) that can handle this for C, or really any other language with similar syntax.

Prettier does it fine for JS, which uses C-style ternary syntax.

> Python's "Black" formatter actually does the best job here, yet the python ternary syntax is still very verbose and strange IMO.

To me, its quite natural when used sensibly, since if you drop everything after the if it is the normal-case value. Though I would slightly prefer if the ternary form was:

  <default-valur> unless <alternative-condition> then <alternative-value>

instead of:

  <default-value> if <default-condition> else <alternative-value>

Prettier does okay, it has some weird edge cases though that make certain code entirely unreadable. But they're rare. I still prefer how Black does things, e.g. splitting complex expressions into multiple lines using parenthesis.

> Though I would slightly prefer if the ternary form was:

Agreed, I do like that much better too.

A lot of bloggers love linters, and they will look for any reason to promote them. They will say things like “programmers don’t like to have their code criticized” and “chicken-little reaction” and other excuses. But fundamentally the problem is that bloggers like to tell others what to do.

Well, tough shit, because I closed the tab.

Those who can, do. Those who can't, teach. Those who can't teach, write blog posts.

> But here’s the reality: most code is not complex enough to warrant while loops, and most while loops are better written as for loops.

Hard disagree. Obviously, if the loop is a fixed number of iterations or iteration over a collection (which is trivial to identify by human inspection but probably not for a linter), a for loop is better but it is not uncommon to be looping until a (possibly compound) condition becomes true that cannot be expressed as a fixed number of iterations or (at least naturally; you can embed arbitrary complexity into a generator, though usually, absent unbounded recursion, that will just push the “while” down behind a layer of abstraction) as exhaustion of an iterable.

I've actually found that there are a number of situations where I really want:

  while True:
    ...
    if condition:
      break
    ...

and kinda wish there was a nicer syntax for this.

Rust has `loop {}` which I thought was weird at first, but also ended up use more than I would have expected.

One especially nice part of rust's `loop` is since it's guaranteed to run at least once and to terminate, you can break with a value!

    let foo = loop {
        // ...
        if condition {
            break value;
        }
        // ...
    }

A Ruby-like “until” or Pascal “repeat...until” (C’s do...while is equivalent but less clear choice of keywords, IMO.) The Pascal form wouldn't really fit Python's indentation-without-closing-marker block syntax preference, but the Ruby version would.

If it existed, I’d be tempted to suggest a linter rule that prohibits break inside an until (it should only be used when the main exit condition is the only exit condition.)

Too late to correct, but I can tell I haven't been using Ruby much for a while; Ruby until is just negated while, like C it uses while (or until!) at the end for Pascal-style repeat...until logic.

And this is where I really miss Sather:

  loop
    while!(condition);
    ...
  end;

for while, versus

  loop
    ...
    while!(condition);
  end;

for do-while, and

  loop
    ...
    while!(condition);
    ...
  end;

in place of:

  while True:
    ...
    if not condition:
      break
    ...

Alas, it never really took off.

In my personal experience, its quite rare outside of a few specific cases where I need unbounded loops. The specific cases where I do need them tend to be event loops -- a game loop, a consume the queue loop, a read and process input loop, etc, basically waiting on some external (to that code, not necessarily to the program) data, forever until the program is told to stop. Sometimes they're provided for me by some library or framework, sometimes I need to write them myself.

Almost every other case, in my own code at least, is a bounded loop. Usually processing a collection, but also often processing bounded ranges.

While I appreciate the idea of bounded loops, it's a mistake to think that a `for` loop is necessarily bounded.

It's pretty easy to write a generator that produces an infinite sequence. That generator, of course, would need a `while` loop, but that loop can be in an external dependency which the linter is not checking.

You also can read way more than you expected if you use a `for` loop to read from a socket, or a file, to say nothing about reading from /dev/random.

Not that it's a bad advice, but it's not a rule, it's more like a... guideline. Discretion is still needed.

You should be able to create an unbounded for loop as well. After all, a python process has mutable state, so it should be fairly simple to increment the length of your loop inside the loop body.

  >>> x = [0]
  >>> for x in xs:
  ...   print(x)
  ...   xs.append(x+1)

Or bounded… by the heat death of the universe. I think there’s a point though, if you’re writing a stack machine or something like that where it makes sense, you’d know. But many novice programmers reach for the old while-bool-var construct and set it to false in the loop body (and often reset it to true later. So confusing. )

Inspired by the boldness of this article, I decided to make my own linter which was going to be the most opinionated of them all.

Since my gut feeling is that 99% of the code is always shit that should not have been written at all, I have coded a linter that simply flags every line of your code and strongly advises you to delete it. And also change your trade if you can.

This linter was a very good invention. But then I got caught up in the spirit of being fair and “eating my own dog food”, and ran the ultimate linter on its own code.

It told me the code was pathetic shit and that I should delete it, and never write a line of code again because very likely it was going to be same shit, but worse.

I followed its advice.

> A while loop introduces unbounded computation.

Then so does a for loop. There’s no difference in this regard between for and while loops: you can use both of them to express both bounded and unbounded computations, and in each case you need to read and understand at least what comes before the colon to know which it is.

  # Unbounded
  while True:
      pass

  # Bounded
  while False:
      pass

  # Unbounded
  for i in itertools.count():
      pass

  # Bounded
  for x in []:
      pass

And you can’t just say “but with for loops you only need to worry about the iterator, whereas with while loops you’ll probably need to worry about statements inside the loop in addition to the loop condition”, as seen in this entirely realistic function that is unbounded if source == target (assuming a port of the DOM API, so child_nodes is a live collection):

  def clone_children_to(source: Element, target: Element):
      for node in source.child_nodes:
          target.append_child(node.clone())

(I agree that for loops are generally preferable to while loops where feasible, but I object to the way you’ve expressed that paragraph, and the expressed reasoning underpinning the entire section is flawed, as priansh also points out.)

I have a much better time with Python just doing what I want instead of following the Python community's sometimes arbitrary and capricious standards.

I mean sure, that’s true of every programming language. The reason to follow community standards is to make the lives of other people reading your code easier. Consistency is far more important than any individual’s optimal style.

God bless gofmt and tools like prettier.

Python has Black, which uses the same premise as gofmt.

Guido doesn't like it, though, but the community seems to.

Which brings up another point -- that's precisely the difference between having the format be essentially part of the language from day one, and shoehorning it in later. The utility of auto formatting comes from instantly eliminating the squabble and bikeshedding.

The article is not representative of the community, quite the opposite.

In fact, the community is embracing "black" these days, the python equivalent of gofmt, exactly because we have better things to do than arguing over PEP 8.

I was thinking back to my earlier days when I'd post questions with code in the freenode python channel and get quibbles about choosing to index an array or not use a list comprehension or which way to format strings. I only ever really write python for quick scripts for myself these days anyway so I guess it's a moot point. Maybe I'll look into what black formatting looks like though.

I just feel like this author could have chosen a better example. The if/else block that he complains about is easy to read and simple to understand. The ternary he advises raises the bar significantly for anyone trying to read the code, while having no practical effect on runtime or usability.

Based on my 25+ years of experience I strongly believe that the "if/else" that this author complains about is actually BETTER than the ternary he recommends. This is yet another example of the endemic problem where software engineers think "harder to read is a virtue".

If expressions are good, but python's hideous middle-endian if expressions are rightfully feared.

Python doesn't have a do..while loop, so when you want to do a thing at least once, the simplest replacement is starting the loop with "while 1:" and ending the loop with "if ... break".

I disapprove of any linter that flags this idiom.

why "while 1:" and not "while true:"?

I think that's brain damage from years of embedded C.

Because "while 1:" is valid Python, but "while true:" is not ;) (gotta capitalize "True").

In addition to the GP's self deprecating sibling comment, I started using Python around 2.2, before there were even "True" and "False". So, seeing a 'while 1' loop is perfectly natural to me. But, I'm also perfectly comfortable with Python's "truthiness" in more places than most people are.

As a bonus: consider "while 'false' :" as a perfectly valid start to an unbounded loop.

> consider "while 'false' :" as a perfectly valid start to an unbounded loop

That sort of thing is ubiquitous in dynamically-typed languages. Even HTML: the state of boolean attributes is determined by the attribute being set, regardless of its value, so <input disabled=false> will give you a nice disabled text box. Mind you, some attributes that you might think would be boolean actually aren’t, for varying reasons good and bad, e.g. autocomplete=on|off, aria-hidden=true|false.

Enjoy YAML with Norway. https://news.ycombinator.com/item?id=17359376

I learned Python around that time, when the docs said that `open()` is deprecated and to use `file()` as a constructor instead. Still unlearning that habit.

Cheers for the history lesson - True and False really are relatively new in Python. I wonder how common that knowledge is.

http://python-history.blogspot.com/2013/11/the-history-of-bo...

https://www.python.org/dev/peps/pep-0285/

It used to be slightly faster in Python 2, because True could be reassigned, so its value had to be loaded and checked with every iteration.

> Python doesn't have a do..while loop

Python doesn't have an “[repeat...]until” loop, which C misspells as “do...while”, which fails to express what is going on.

> so when you want to do a thing at least once, the simplest replacement is starting the loop with "while 1:" and ending the loop with "if ... break".

“while True:” is more idiomatic Python (“while 1:” works since 1 is truthy, but using a literal 1 for “True” is a C-ism, Python has True as a literal for quite some time and idiomatic Python uses it.)

Actually the most idiomatic way to write this is `while "False":`

People raging over the ternary operation in Python should learn to use:

  x = {True: 5, False: 4}[condition()]

, or if you don't want to evaluate the values:

  x = {True: lambda: 5, False: lambda: 4}[condition()]()

This pattern also nicely expands when you need to select from more than 2 values. And it lets you keep the mapping as a data instead of turning it into logic.

  {"a": 1, "b": 2}.get(selector(), default_value)

for the else-case.

This is perhaps one of the most obscure ways to do ternaries I could have thought of, and while it really is quite clever, I think I'd be pretty annoyed if I encountered it in the wild.

    x = (4, 5)[condition()]

for a bonus "what am I looking at again?"

Brilliant.

Well, he's right that it's opinionated. If I were to contribute to that project I'd opinionatedly implement the exact opposite linter, suggesting proper if blocks instead of a ternary expression.

The reason is simple: visual code structure.

A bespoke if block provides you with appropriate visual semantics that that part of the code involves a decision point.

By contrast, the ternary operator is useful when you want to visually obfuscate that fact, and make the code terser and more focused on the fact that an assignment is taking place, whose value is determined by an expression (which upon closer inspection happens to be conditional).

Yes I know that in the age of super-fat IDEs everything is but a search away, but, I've just come off from reading that other article from today about the guy who handwrites all his code.

So clearly low-level visual structure and ease of mental debugging still matters, no matter how bloated and feature-full your IDE is.

But what do I know. I still code on vim/nano.

This! When reading/skimming through source code I find the structure very important to understand that a decision is being made and not just a simple variable assignment.

Sometimes more code is easier to read than shorter code. Even

I love linters.

This is one of the first things that I add to a new project, before I write one line of code: https://github.com/realm/SwiftLint

I write about it here: https://littlegreenviper.com/miscellany/swiftwater/swiftlint...

Hating linters is like hating a weight scale for telling you your weight, or hating a blood exam for telling you that you have high cholesterol.

If the linter says your function is too long then you refactor it, you don't turn off the linter. You also fix it immediately, not "later" (broken windows theory) before the next offender copies and pastes the offending code or continues making it worse.

In underdeveloped countries, governments manipulate the definition of unemploment to make themselves look better. Does that solve anything? no. It actually makes things worse because now you cannot mobilize people and resources to solve a problem you don't have. It's wrong. And so is turning off linting.

Linters tell you when your code doesn't respect certain rules. That's it. These rules may or may not lead to better programming, that depends on the rules themselves. I could build a linter that forbids all variable names longer than three characters. Would that make the code good? I doubt it. Sometimes the extra weight you notice on the scale is just muscle, and there's nothing to worry about.

That's a straw man argument.

That's not an argument but an example. You associated linters and scales saying that people hate them because they tell the truth. My argument is that the truth that these tools express is limited. A basic scale can only tell you if your weight went up, down or stayed the same. It's a useful information but it lacks context and can be misinterpreted if taken alone. Same thing with a linter. While the linter is supposed to encode best practices, code doesn't exist in a vacuum and had a context. For every linting rule, there is probably a certain number of good reasons to break them.

> You know what else doesn’t have unbounded loops? Excel.

Right, one of the many reasons why nobody (with half a brain) hosts a web server in Excel.

I wonder how much "boring web app" experience the author had. If I'm debugging on 11 pm why the webserver is timing out talking to microservice A, but only if it first opened connection to service B, and someone strolls along saying "Hey, your code is bad because it's using unbounded computation," then god help us, because I might lose it. (Well, shrug, the worst that can happen is that I may rage-quit on the spot. I'm not a very imposing guy.)

That's why you want to start thinking macro and holding your code to a high standard early. You can, for the most part, avoid firefighting if you don't let things fester.

If you're in charge, that is...

Well, sure, you're absolutely right that it's best to write high-quality code so that you avoid firefighting in the first place. But that's an orthogonal question to whether the number of while loops is relevant to code quality. Most programs (or even subtasks) aren't Turing machines - they are "unbounded" in that they're supposed to run indefinitely until someone tells them to quit, or until they abruptly hit EOF, end of stream, whatever. You don't improve such logic by making them "bounded" - it will be in fact missing the point.

* If you prefer, change 11 pm to 11 am and my point still stands (though I'll be less cranky and less likely to rage-quit).

Congrats on insulting someone you don’t know because he made a valid point without saying anything about the point they made.

They love linters, you sound like you hate linters. Don’t use them and let your colleagues deal with your unbounded computation.

>most code is not complex enough to warrant while loops,

  scale = 5

  while (scale > 0.1):

    do_stuff(scale)

    scale = scale/2

Sure, you could use exponentials with range(), but is that really clearer?

Even clearer:

    scale = 5
    # The alternative would be exponentials with range(),
    # but it's clearer to use 'while'
    # pylint: disable=[while-used]
    while (scale > 0.1):
        do_stuff(scale)
        scale = scale/2

Less sarcastically, how about:

    scales = itertools.takewhile(
      lambda n: n > 0.1,
      functools.reduce(lambda x, y: x / y, itertools.repeat(2), 5)
    )
    map(do_stuff, scales)

This would be even easier with an 'iterate(x, f)' function which generated (x, f(x), f(f(x)), ...), but I couldn't find one in Python's builtins:

    scales = takewhile(
        lambda n: n > 0.1,
        iterate(5, lambda x: x / 2)
    )
    map(do_stuff, scales)

Poe's law demonstrated.

Indeed, though in a language designed for this style of programming, the idea behind that final example in the GP comment works fine. A Haskell version might look something like this:

    iterate (/2) 5.0
      & takeWhile (>0.1)
      & map do_stuff

The `iterate` generates the infinite sequence, the `takeWhile` specifies how much of it to use, and then we do stuff with each element.

This is arguably a little nicer than the while loop since it exposes the real sequence of values you’re working with more explicitly, but at the very least it is comparably simple in its appearance. The Python version in the GP comment looks bad mostly because of the clumsy lambda syntax.

I shouldn't need to read the code extremely closely or repeatedly to have to figure out what it does when the while loop does it clearly (and in a bounded way that you can literally mathematically prove).

Also, I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase.

Why does the linter rule not, instead, check if the while loop is unbounded and warn the user of that? Surely screaming fire when there's an actual fire is better than screaming fire at the first sign of smoke.

> Why does the linter rule not, instead, check if the while loop is unbounded and warn the user of that?

Indeed, the linter only needs to incorporate of the many known solutions to the halting problem.

unBounded = null

> I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase.

That sounds like a bad situation, but it completely depends on "every time we use a while loop". The entire point of lint checks is to reduce the occurrences of certain patterns (like while loops, in this case). This post is arguing that "every time we use a while loop" should ideally be the same as "never", in which case you're still correct, but vacuously so.

For a less controversial example, try running your comment through sed 's/while loop/eval/g'. There are certainly situations where 'eval' is the only way to do something; and other situations where 'eval' would be more readable/efficient (e.g. compared to writing a file and spawning a subprocess). Yet we go out of our way to minimise our reliance on 'eval', and I certainly wouldn't mind adding a pylint-disable comment for those times I use it (every few years).

Or you can use a for to satisfy the linter that is more in the spirit of the while loop, albeit at a cost of O(n) memory where n is the number of iterations the loop takes:

  scale = 5
  t = [1]
  for i in t:
    do_stuff(scale)
    scale = scale/2
    if scale > 0.1:
      t.append(1)

Ironically (to me at least, because it's a construct I use -far- more rarely than while), this actually seems like a case where a C-style for loop might actually be nicer:

    for (my $scale = 5; $scale > 0.1; $scale /= 2) {
      do_stuff($scale);
    }

While I agree with the ternary linting, the while loop piece makes absolutely no sense. There are absolutely many, many use cases of while loops; in fact, many dynamic programming algorithms rely on them.

Could you write them as a for loop? Possibly, but why? Is the new 2021 programming fad hating on while loops? Who do I contact to exchange my "js bad" t-shirts for "while bad" laptop stickers?

The logic behind disapproving of while loops in the article seems to stem from the author assuming while loops are "unbounded." This is absolutely, completely, totally false and there are entire branches of reasoning dedicated towards observing the bounded-ness of while loops. Most colleges include this in their curriculums and you usually have to learn to prove (via induction) the variants and invariants surrounding your loop before you can pass basic classes. It's even more ridiculous that, in the same breath, the author assumes for loops are guaranteed to complete execution. I can disprove this in two lines of code and two braincells:

  for x in infinite_generator():
    do_something()

This is also the general structure that message-queue libraries like Kafka, RabbitMQ etc take with their python code. Not to mention that, in many programming languages, for-loops are actually implemented as while loops behind the scenes.

I'll cede that it's easier to write unbounded code with while loops than for loops, but this is programmer error that can be pretty easily avoided by simply being a teensy tiny bit careful (and can be easily corrected). I'd also argue that the majority of these cases where while loops can be substituted by for loops, are also cases where writing a while loop is much simpler than trying to convert into a for loop. (Besides, you could make any of these arguments about recursion.)

> You know what else doesn’t have unbounded loops? Excel.

This is also a lie, Excel absolutely has infinite loops, it just yells at you when you do it. The equivalent of this in programming is a linter. Instead of just screaming fire every time the user writes a perfectly fine while loop, why not concentrate your efforts on identifying unbounded loops and introducing a linter rule for that?

Honestly, it's absolutely terrifying to me that someone contributing to the predominant linter for a major programming language not only wholeheartedly believes while loops are always unbounded and usually evil, but also managed to get this introduced (and presumably approved) by reviewers of this linter, and then proceeded to gloat about it on HackerNews. It comes as no shock to me that most people I've worked with disable pylint in their editors if they're this unreliable with their review process.

Did you miss the fact that these rules are disabled by default?

It should never have been introduced or approved in the first place.

I think there is a place for it, though it was poorly justified in the article.

It depends on the type of programming you’re doing.

Algorithmics routinely does stuff that matches while loops and C-style for loops while loops, but doesn’t match iterator for loops very well.

In most parts of line-of-business sort of software development (and that’s the significant majority of software development, frankly, certainly a lot bigger than algorithmics), I’d say it’s rare for a while loop to be desirable: it should almost always be iterator-powered instead.

I think the C-style for loop thing is a particularly interesting aspect to this: I suspect most code that uses while loops where an iterator would not be appropriate would actually be at least as well-served by a C-style for loop. But Python made a deliberate decision not to have C-style for loops, because most uses of them are better-served by iteration. And so this nudging from while to for is really a perfectly natural extension of that.

Still, all things being considered, it’s not the sort of lint that I would ever turn on for myself or for code that I review, because I know when to use each.

"it unconditionally flags every use of while expressions."

I'd find that pretty annoying.

Consider a while loop in a thread:

  while not quit_thread_requested:
    # do threaded task

I agree, but to fair to the author I do not think the vast majority of people are implementing thread pools in python.

I also think there were good reasons the author's linters were left as optional, and its probably not because everyone thought they were great ideas.

> I agree, but to fair to the author I do not think the vast majority of people are implementing thread pools in python.

This trope needs to die. While loops are a basic language feature. A thread pool is one very specific example of where that language feature is necessary. Every very specific example is trivially dismissed with "the vast majority of of people aren't doing that very specific thing." It's the laziest rebuttal, and not even wrong.

Cool things I've seen written in python that need while loops: http servers, games, more generally anything that listens on a port or depends on user input, mathematical code that depends on computing a base-k representation, stack-based algorithms...

Hold on, let's stop there. Python sucks at recursion. So bad it's capped at a very small depth. The only reasonable workaround is to avoid the call stack and roll your own, which involves... you guessed it, a while loop. So, this linter prefers buggy stack-smashy code. That's nice. Adults can use another linter.

Did you read the second half of my post? Did you read the authors post at all?

> anything that runs for as long as the user says it should run;

FWIW, ternary expressions aren't properly detected by coverage: https://github.com/nedbat/coveragepy/issues/509

Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.

I am not a fan of the examples in the article, but for tools like rubocop in ruby, I am pretty glad it sometimes uses semi-obscure but more "correct" forms.

When I started learning ruby a bunch of the changes flew over my head, but it is also an excellent entry point to look further into best practices, and concrete examples of how my code could be better.

The condition is of course the tool being itself extremely good, otherwise it's just everyday hell (looking at you, phpstan...)

Python is a sane language that you can master in a reasonable amount of time.

If you think expecting people to achieve Python mastery is unreasonable, wait until I tell you about language called C++.

Agreed, but I work with a lot of sysadmins who will never master Python. They'll use it, but never be at the level of a software developer. And that's OK because they have tons of other skills which are super valuable. I'd rather have our monitor scripts and glue code be more readable than complex.

I would never demand this for someone writing a Python app or module that out team would use as a normal import, just the stuff we actively manage.

I agree with the general concept of "Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers." but this does not seem applicable here - it's not "expert level" coding, the suggested method is obviously readable to anyone who writes Python and is something that a programmer who has never used Python would learn in their first day of learning Python, it's not an advanced concept.

Probably the whole concept of idiomatic Python is that there shouldn't be different styles of Python to which you graduate according to skill or experience, but rather that the simple, readable way of writing things should be done by everyone, always, from novices to experts. Code-golfing with dense weirdness would be "anti-Pythonic" but this ternary expression would be readable even for if someone who's never seen Python would read it as pseudocode in some theoretical CS paper.

in general i agree, but i'm not sure what you're referring to as "expert level" here - if it's ternary operations, those a pretty basic concept, and i don't think there's a clear argument to be made that they're more or less readable than expanding out the if statements, it mostly just comes down to preference.

Some (including me) would argue that writing any loop yourself is considered harmful and you should be better of using higher order functions.

In Haskell there is a higher order function for basically every usecase and (most of the time) the compiler is smart enough to merge chained higher order functions into a single loop.

Python is at least trying with its `itertools` package, but it's still a far cry from the generalization "modern" languages allow.

(Background: I was fortunate enough to program in Haskell for 2 years. It was great, but I can see that it's basically useless for a lot of common usecases :-( )

Okay, so how should the following loop be rewritten:

    while self.keep_going:
        s = input('> ').lstrip()

        if s == '':
            continue

        cmd = self.parse_cmd(s)
        
        # The "quit" commands sets self.keep_going to False, oh the horrors
        # of the global mutable state
        cmd()

? Should it be:

    for cmd in self.stream_of_commands():
        cmd()

But stream_of_commands() will still have a loop inside it, wouldn't it? Because that's how you write generators?

The author mentioned this at the end, but banning while loops (and any other way for running a loop with a priori unknown number of iterations) actually decreases the expressiveness of a language - it becomes no longer Turing complete. A classic example is the Ackerman function - it cannot be computed in a primitive recursive language.

(The author is on point when they say almost all code used in practice is primitive recursive, though)

I think “while loops” are orthogonal to primitive recursive functions.. for example, here’s how to compute the Ackerman function using only recursion in several languages; https://stackoverflow.com/questions/16115815/ackermann-very-...

It doesn't have to be a while loop. Recursion is another way to implement a loop with a priori unknown number of iterations. You can also use goto.

And no, they aren't othogonal. A simple language with only integer variables, basic arithmetic, if() and for(i in range(x,y)) is actually not Turing complete.

i think the key point is that the linter doesn't ban anything. nobody is proposing removing while statements from the language. if you have a valid case for disobeying the linter, then you can disable the linter for that line: https://pylint.pycqa.org/en/latest/user_guide/message-contro...

(if a project unconditionally bans PRs that don't pass the linter, that's a different issue, and not really the linter's fault)

I could certainly see a linter that says "are you sure?" before you initially add a while loop to make you ask yourself if that's really the best option being quite neat.

The trick would be making it sufficiently useful and minimally annoying that people don't get angry and turn it off.

it's not really the linter's job to say "are you sure". the linter just applies the rules and generates messages, it's up to you to do with those messages what you will

when using the python integration in vscode (which runs pylint), clicking on a linter error gives me a context menu where one of the options is essentially "are you sure?" and will automatically adds the appropriate comment to disable the linter for that line.

I was thinking along the lines of something similar except for running the linter as a pre-commit hook.

I’m ~intermediate at python and understand the arguments in this article, but the comments are so negative and varied that i don’t know how to make sense of the contrary. Could somebody please share some more advanced resources about while loops/for loops/iterables, or point me in the right direction?

My understanding is that the blog post is a bit too opinionated, dismissing valid uses of language features with a perceived condescending tone.

The ternary operator is mostly a matter of style, and just be aware that for loops is often a better way to iterate through things than while loops. I wouldn't worry too much.

Unbounded computation is necessary when working on either event driven architecture (block/wait for something, run it, block/wait again) or working with frames.

I can’t imagine making a game (though not sure who makes games in python) without a while loop to run on the main thread.

Right, luckily it's not enabled by default. Some other fields in which unbounded computation is common are IOT and robotics.

The ootb linter setups I've seen offer little useful checks, just everybodies feelings about your code, so personally don't find them useful. This article is a prrfect example of that, but kudos to the author for being honest about it.

Claiming that the 'too many false positives' objection is just an excuse for not liking having one's code criticized is itself just an excuse for dismissing a real problem with linters. When writing code from scratch, I am generally eager to use static checking, but when I am flooded with complaints about things I cannot reasonably do anything about, it becomes useless.

...And I wrote 'generally eager', because having a linter raise pedantic concerns over trivial matters is a way to extend this problem across from-scratch code as well.

I always had the vague impression that the original purpose of linters was for some arrogant ahole to impose his "style" on other people. Now I have confirmed this impression.

So is the author suggesting that a while loop like this:

    while not quitRequested:
        processNextEvent()

Should be rewritten to this?

    for i in range(999999):
        if quitRequested:
            break
        processNextEvent()

Because that's supposedly guaranteed to halt? If so he's either joking or crazy. And his program will crash for his poor users after 999999 events.

I guess `quitRequested` falls in:

> anything that runs for as long as the user says it should run;

Per the article...

Well his linter flags every occurrence, apparently. Because "that’s the fact of the matter, and you need to come to grips with it."

If you enable it. And if you really care about avoiding while-loops, you can still silence it for the ones you really want to have (e.e. main loops like your example, as also mentioned in the article).

Probably not for me though.

In practice, quitRequested and processNextEvent are probably both members of some managerial object; perhaps like this:

  while not loop.quit_requested:
      process(loop.next_event())

And when you see it like that, then it becomes more apparent there’s an obvious way for it to be an iterator:

  for event in loop.run():
      process(event)

This is typically harder to get wrong, and generally matches the semantics of what you’re trying to do more closely: process a stream of events. You didn’t actually care about quit_requested, you cared about the events.

And so in this you can start to see why iterator-based for loops are normally better than while loops (and C-style for loops, which Python doesn’t support): while loops (and C-style for loops) are generic bookkeeping, with no specific semantics on the while condition (or for init/condition/increment clauses); but iterator-based for loops operate on actual data.

This principle can be seen in resource locking also; you don’t want a lock object beside the data that it locks, like this:

  with lock.acquire():
      queue.append(item)

That style is just asking for trouble; sooner or later you’ll touch the queue without acquiring the lock, and everything will fall apart. Instead, you want to lock the actual data so that you can’t even access the locked thing without acquiring the lock:

  with queue.lock() as q:
      q.append(item)

P.S. If you deal with something like the original loop without a run() method, you can write a generator to convert a while loop into a for loop:

  def run(loop):
      while not loop.quit_requested:
          yield loop.next_event()

  for event in run(loop):
      process(event)

Most of the time the difference won’t be significant or worth it, but sometimes this can really help to clarify things, by extracting the loop bookkeeping into one place so that you can do what you were semantically trying to do, processing a stream of events.

P.P.S. Instead of range(999999), use itertools.count() when you want unbounded iteration. Or itertools.repeat(None) if you don’t care about the number—but in that unused number or None see that a for loop is probably not the right tool for what you’ve written: you would be better either shifting back to while loops, or iterating over the data as I’ve demonstrated.

I usually do some sort of maximum recursion check. For things where I’d expect for example max 10 levels, I’d check for 1000-10000, and then raise an exception.

In Python? Apparently the default for RecursionError is already 1000.

For other languages, you might still hit stack overflow (not the site) before you get to 10000 if the stuff you push on the stack is large-ish.

Is this a joke, right?

    Do you really need unbounded computation for your boring web app?

Because everyone using python is working on web application. Also because all web applications have the same type of business logic.

I do like linters, the best ones help avoiding mistakes and ensure some consistency in the codebase, but this article goes a bit too far.

Sure, once you cherry-pick the most trivial imaginable example ternary expressions are easy enough to read. First counter-example which came to mind:

  print("yes") if random.choice([True, False]) else print("no")

Does this do the right thing? I was pleasantly surprised to find that this is indeed lazily evaluated, but that's not at all intuitive: first because `print("yes")` comes before the conditional (note that the Lisp example had the conditional first), and second because not all popular languages work like that.

There are lots of examples where ternary makes things obviously harder to read, such as when at least two of the three expressions are non-trivial. Which one would you rather read?

  if some_complex_condition(using, four, different, parameters):
      do_a_thing(now, using, five, different, parameters)
  else:
      do_another_thing(with, three, parameters)

  do_a_thing(now, using, five, different, parameters) if some_complex_condition(using, four, different, parameters) else do_another_thing(having, three, parameters)

(or

  do_a_thing(now, using, five, different, parameters) if some_complex_condition(
      using, four, different, parameters
  ) else do_another_thing(having, three, parameters)

after Black.)

Neither of your examples qualify for the lint rule that's about cases that assign to the same variable, so I'm not sure why you accuse the author of "cherry-picking"?

I didn't realize this was only for assignments, but the same applies if you prepend `x =` before the relevant lines.

I would write it like this. Seems fine to me

  do_a_thing(now, using, five, different, parameters
      ) if some_complex_condition(using, four, different, parameters
      ) else do_another_thing(having, three, parameters)

Theses are good examples for not using ternary expressions. The code looks wrong even if it is correct, and it is hard to follow.

There is a very simple rule avoiding most of these issues - if the ternary expression does not fit in one line, use if/else.

> Python programmers in general have an irrational aversion to if-expressions

If that's the case, maybe the problem is the if-expression, and not the programmers?

If you have a syntactical construct in your language that the programmers are avoiding in general, then that construct has problems.

Linters are good because they stop people arguing. Some early employee in the team defines some set of rules, and that's just the way things are from then onwards.

Less time bickering means more time spent doing actual productive stuff.

Linters are bad because they force your code into unnatural shapes, preventing you from exposing visual patterns and harming code comprehension, and also regularly harming diff sizes.

(Both of these statements can be true.)

True. Both can be true! :-p

I don’t agree with these opinionated defaults, but I’m primarily a Ruby programmer so my tolerance for expressive code is higher. As long as the linter is configurable I don’t really care.

Something tells me the author would appreciate the minutia of working in functional languages that tend to avoid entire classes of problems like those described and the dogma used to fight it.

I have more problems with:

- extensive small functions/methods

- people who don’t use early escapes

What's the problem with small functions?

In one of Raymond Hettinger's YouTube presentations, he speaks slightingly of pylint. These days I use flake8, but not pylint.

> less code is better than more code, and this block can be rewritten more concicely

Conciseness is not necessarily better.

- Does this idiom make debugging easier? no, it doesn't.

- Does this idiom make it easy to identify where a branch starts and ends? no, it doesn't. Before you could use indentation alone, now you have to read the statement.

- Is it slightly faster to type? Maybe. But that does not matter because time spent typing is a tiny tiny fraction of the time you spend as a developer. You spend much more time reading than typing.

How is this new ? Perhaps it's new for the author. Python one liner ifs were not introduced yesterday.

> A while loop introduces unbounded computation

Someone needs to inform this guy that generators exist

i dunno re: the while loop -- a while loop with a condition that breaks the loop is perfectly fine by me.

There shouldn't be so many ways to do loops. Assembly got it right the first time.

I just want to read and write:

    x = if condition(): 4 else: 5

https://xkcd.com/1833/ has some good ones.

Most of the time when I see python ternary in the wild, it makes the code less readable, not more. Why not just define something like this if you want oneliners?

  def if_then_else(cond, true_case, false_case):
      if cond:
          return true_case
      return false_case

  x = if_then_else(condition, 4, 5)

Consider this:

    x = if_then_else(condition, calc1(), calc2())

Here it will call both calc1 and calc2 even though it will ignore one depending on condition. They might be expensive operations, or might have side effects that you don't want. The original code does not evaluate the part that is not used

In that case I'd stick an `if callable` check in if_then_else. But really... ternary is a nice way to draw attention away from simple pieces of code. If you have anything complicated (like functions with side effects) spend the extra 3-4 lines to make it readable

Reply on news.ycombinator.com