[deleted]
New Ways to Be Told That Your Python Code Is Bad
251–260 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#252> 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 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 []
...Re: New Ways to Be Told That Your Python Code Is Bad
#253I’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.
Re: New Ways to Be Told That Your Python Code Is Bad
#254Ah, 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.
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.
Re: New Ways to Be Told That Your Python Code Is Bad
#255> 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 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 nat…
> 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.
Re: New Ways to Be Told That Your Python Code Is Bad
#256So 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 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.
Re: New Ways to Be Told That Your Python Code Is Bad
#257Most 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
Re: New Ways to Be Told That Your Python Code Is Bad
#258Earlier quoted context omitted.
It is simply a design choice, the common value is given first. Comprehensions in Py are the same.
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 progra…
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.
Re: New Ways to Be Told That Your Python Code Is Bad
#259Ah, 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…
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 o…
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.
Re: New Ways to Be Told That Your Python Code Is Bad
#260Earlier quoted context omitted.
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?
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,…
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!