Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

Post reply on HN
Print view View original

151–160 of 262 posts

Re: New Ways to Be Told That Your Python Code Is Bad

#151

Post by jstanley »

MathMonkeyMan wrote: post #148
ohazi wrote: post #122

> 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 thing…

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 U…

> 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)

Re: New Ways to Be Told That Your Python Code Is Bad

#152

Post by [deleted] »

ghgr wrote: post #140
_ZeD_ wrote: post #132

I have problem with both new checkers: regarding the `consider-ternary-expression` if condition(): x = 4 else: x = 5 allow me to put f ck'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…

> 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)

[deleted]

Re: New Ways to Be Told That Your Python Code Is Bad

#153

Post by MathMonkeyMan »

jstanley wrote: post #151
MathMonkeyMan wrote: post #148

Earlier quoted context omitted.

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 U…

> 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)

Re: New Ways to Be Told That Your Python Code Is Bad

#154

Post by boomlinde »

matusp wrote: post #107

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()]()

    x = (4, 5)[condition()]
for a bonus "what am I looking at again?"

Re: New Ways to Be Told That Your Python Code Is Bad

#155

Post by junon »

dragonwriter wrote: post #126
zootboy wrote: post #4

> 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

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.

Re: New Ways to Be Told That Your Python Code Is Bad

#156

Post by wodenokoto »

ohazi wrote: post #122

> 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 thing…

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.

Re: New Ways to Be Told That Your Python Code Is Bad

#157

Post by fho »

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 :-( )

Re: New Ways to Be Told That Your Python Code Is Bad

#158

Post by drcongo »

ohazi wrote: post #122

> 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 thing…

I love the Python version, it reads like English.

Use umbrella if raining, else wear shades.

Re: New Ways to Be Told That Your Python Code Is Bad

#159

Post by heresie-dabord »

MathMonkeyMan wrote: post #144

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…

> 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.

Post reply on HN