Live data from Hacker News

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

codereviewdoctor.medium.com

101–110 of 339 posts

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

#101
post #93

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.

Hmmm, it sounds like you're expecting "two" and "three" to be separate list elements because of some sort of implicit behavior due to being written in a list context. This is the opposite of what "Explicit is better than implicit" means. This is a list and you must explicitly place a comma when you want to start a new element in the list. Is there ever a time a new element follows a previous one and is NOT separated…

> it sounds like you're expecting "two" and "three" to be separate list elements

I'd expect that to be an error.

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

#102
post #74
post #52

Earlier quoted context omitted.

The errors were usually in tests themselves. Are you arguing that tests need their own tests to test that they are testing the right thing? Usually I think people believe that tests do not need to be tested and should not be tested, i.e., that you measure "100% coverage" against non-test code alone.

I don't think anyone could disagree: you could never exceed 0% code coverage if your definition was recursive (i.e. included tests, tests-of-tests, tests-of-tests-of-tests, ...).

Only if you generate infinite tests, then your coverage approaches 0%. But 100% covered code + 0% covered tests = ~50% total coverage.

Also, the obvious solution is self-testing code. (Jokes aside, structures like code contracts attempt something like this).

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

#103

Earlier quoted context omitted.

Keywords like namespace , no; but functions and classes and modules provide for a lot of scoping opportunities.

The problem is `fop` should be `foo`: foo = 5 fop = 6 Keywords like `let` solve this problem: let foo = 5 fop = 6 # error

Or := for declaration like Go and Toit

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

#105

Earlier quoted context omitted.

or if that's the use case, require the whitespace to include a \n or \r\n... It's not like python doesn't have significant whitespace already.

That wouldn't fix most of the cases highighted by the tool in the article. So strange that Python has completely different syntax from C, but they chose to copy this obscure syntactic feature _even though they have the plus operator on strings_.

No post body was provided.

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

#106

For those looking to avoid this specific problem, there is a flake8 rule: https://pypi.org/project/flake8-no-implicit-concat . More broadly, the https://codereview.doctors makers are making the point that their tool caught an easy-to-miss issue that most wouldn't think to add a rule for. A bit of an open question to me how many of those there really are at the language level, but still seems like a neat project.

Also all but 1 of the issues they found relates to test code, it seems people are a little less careful compared to functional code.

Also in terms of mistakes codereviewdoctor twice linked to the same issue in their blog https://github.com/tensorflow/tensorflow/issues/53636 and raised the PR to the wrong project https://github.com/tensorflow/tensorflow/pull/53637 (I guess Tensorflow vendors Keras, easy mistake)

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

#107
post #80
post #12

I am a bit in shock. Accidental string concatenation. Python just lost a lot of reputation in my brain.

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code). The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between

("foo" "bar", "baz")

and

("foo", "bar", "baz")

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

#108
post #30

Earlier quoted context omitted.

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.

Matplotlib is an example of a library with at least two "correct" ways of plotting

Which two ways?

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

#109
post #30

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.

It's sort of like the Unix Philosophy. It sounds good and is probably a good thing to strive for generally, but it's ultimately pointless when it comes to actually evaluating whether approach A is better than approach B.

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

#110

The high-level goals of python end up creating these little syntactic landmines that can get even experienced coders. My personal nomination for the worst one of these is that having a comma after a single value often (depending on the surrounding syntax) creates a tuple. It's easy to miss and creates maddening errors where nothing works how you expect. I've moved away from working in Python in general, but I think t…

I’ve been writing Python professional full time for 8 years and still occasionally make the trailing-comma-tuple mistake. These days at least I’ll recognize and be able to find it quickly rather than wasting time. Can be caught with a linter, but not every codebase is readily linted.
Post reply on HN