New Ways to Be Told That Your Python Code Is Bad • Hacker News Board

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

#231

Post by clownpenis_fart » Fri, Sep 03, 2021, 2:35 PM UTC

fho wrote: post #157

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

ah yes, surely it is possible to restrict yourself to a subset of the language that is guaranteed to terminate and is therefore not turing complete and still be able to implement anything you want

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

#232

Post by Zababa » Fri, Sep 03, 2021, 2:39 PM UTC

zzbzq wrote: post #204

Zababa wrote: post #171

Earlier quoted context omitted.

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

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

#233

Post by mannykannot » Fri, Sep 03, 2021, 2:39 PM UTC

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.

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

#234

Post by shhsshs » Fri, Sep 03, 2021, 3:02 PM UTC

klyrs wrote: post #215

ghgr wrote: post #140

Earlier quoted context omitted.

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

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

#235

Post by klyrs » Fri, Sep 03, 2021, 3:05 PM UTC

shhsshs wrote: post #234

klyrs wrote: post #215

Earlier quoted context omitted.

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.

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

#236

Post by westurner » Fri, Sep 03, 2021, 3:09 PM UTC

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…

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]

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

#237

Post by brundolf » Fri, Sep 03, 2021, 3:21 PM UTC

strken wrote: post #224

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…

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.

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

#238

Post by inanutshellus » Fri, Sep 03, 2021, 3:43 PM UTC

pierrebai wrote: post #214

inanutshellus wrote: post #193

Earlier quoted context omitted.

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…

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

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)

vs

   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.

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

#239

Post by chriswarbo » Fri, Sep 03, 2021, 4:03 PM UTC

sumtechguy wrote: post #209

jackdh wrote: post #118

Earlier 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?

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…

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.

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

#240

Post by SavantIdiot » Fri, Sep 03, 2021, 4:09 PM UTC

mst wrote: post #71

SavantIdiot wrote: post #40

Earlier quoted context omitted.

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.

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+els…

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