5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

Post by Spivak » Fri, Jan 07, 2022, 7:02 PM UTC

kazinator wrote: post #82

Spivak wrote: post #54

Earlier quoted context omitted.

I'm gonna disagree on the import thing. Compared to Ruby where requires are magic bags of metaprogramming bullshit, Python is much much easier to reason about. It takes some getting used to that require 'json' actually adds methods to existing classes.

"require 'json'" is just another #include in disguise, and if it monkey patches existing classes, it ... probably should not exist in any form. If the language supports json, it should just do that. 1> #J[1,2,3] #(1.0 2.0 3.0) 2> (get-json "[1,2,3,{\"foo\":true}]") #(1.0 2.0 3.0 #H(() ("foo" t))) 3> (put-json #(1.0 2.0 t)) [1,2,true]t

    $ irb
    irb(main):001:0> { hello: "world" }.to_json
    NoMethodError (undefined method `to_json' for {:hello=>"world"}:Hash)

    irb(main):002:0> require 'json'
    irb(main):003:0> { hello: "world" }.to_json
    => "{\"hello\":\"world\"}"

Post by lanstin » Fri, Jan 07, 2022, 7:04 PM UTC

lumost wrote: post #75

samhw wrote: post #65

Earlier quoted context omitted.

I think 100% code coverage is folly. Spreading tests so widely near-inevitably means they're also going to be thin. In any codebase I'm working on, I would focus my attention on testing functions which are either (a) crucially important or (b) significantly complex (and I mean real complexity, not just the cyclomatic complexity of the control flow inside the function itself).

Fully agree, but I never want to see a missed function argument programming error in customer facing code. In python you really do need code coverage to achieve this goal - static languages have some additional flexibility.

Post by voltagedivider » Fri, Jan 07, 2022, 7:08 PM UTC

jstx1 wrote: post #135

voltagedivider wrote: post #125

Earlier quoted context omitted.

You're right that both iterate through something but `for` loops and comprehensions aren't used as if they were interchangeable. For example, you'll sometimes see people do bad stuff like this: >>> lst = [] >>> >>> [lst.append(i + i) for i in range(10)] [None, None, None, None, None, None, None, None, None, None] >>> >>> lst [0, 2, 4, 6, 8, 10, 12, 14, 16, 18] >>> When they should be doing this: >>> lst = [] >>> >>>…

The first append version will more often be in a loop. It's unlikely that someone will know enough to use comprehensions but not enough to still use append.

Post by marcosdumay » Fri, Jan 07, 2022, 7:11 PM UTC

jofer wrote: post #115

jstx1 wrote: post #94

Earlier quoted context omitted.

But only one of them is recommended - the one that makes less sense.

How is working with figure and axes objects the one that makes less sense? Is it really that crazy do set up a figure, axes on that figure, and plot on the axes, returning an artist object for each plotting command?

Post by fault1 » Fri, Jan 07, 2022, 7:11 PM UTC

jstx1 wrote: post #30

usrbinbash wrote: post #11

Literally the second item in the "Zen of Python" ( https://www.python.org/dev/peps/pep-0020/ ): Explicit is better than implicit. And yet, s = ["one", "two" "three"] will implicitly and silently do something, that is probably wrong most of the time.

I mean the zen being wrong is kind of a meme at this point. The whole “only one obvious way to do it” isn’t just false but the exact opposite is true. Python is one of the most flexible languages with many many ways to do the same thing; more than any other language I can think of.