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

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

codereviewdoctor.medium.com

Post reply on HN
Print view View original

61–70 of 339 posts

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

#61

Post by ReleaseCandidat »

obua wrote: post #39
ReleaseCandidat wrote: post #25

Earlier quoted context omitted.

I'd say unexpected behavior is always worse than expected one. Yes, you'll certainly find somebody who doesn't know what 'not statically typed' means, but ... And yes, there are also C(++) users, that expect strings to be concatenated like that.

You seem to also not know what "not statically typed" means. It certainly does not mean "not properly scoped".

Yes, of course. But you see that no scope keywords exist in Python. But there exists `+` to concatenate strings (too).

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

#62

Post by micimize »

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.

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

#63

Post by benesch »

oa2022 wrote: post #41
wodenokoto wrote: post #15

Earlier quoted context omitted.

The rejection notice seems completely counter intuitive to me. How is adding a plus "harder" compared to removing a foot gun? > This PEP is rejected. There wasn't enough support in favor, the feature to be removed isn't all that harmful, and there are some use cases that would become harder.

This change would break a lot of legacy code for no good reason The most common way to split a string in lines is using this concatenation formula.

> This change would break a lot of legacy code for no good reason

Preventing a bug that occurs in 5% of observed codebases (and anecdotally, happens to me during development all the time) seems like about as good as reasons get.

Swapping a perfectly fine print statement for a function, on the other hand… that’s the breaking change in Py3k that’s never seemed worth it to me.

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

#64

Post by bilalq »

The whole "666" thing really threw me off. I thought it was some Python specific term or something at first glance. They open with a sentence that mentions "5% of the 666 Python open source GitHub repositories" as though there were only 666 total open source Python GH repos. Picking a number with other fun connotations or whatever to use as a sample is fine, but without setting that context, it was kind of distracting from their main content.

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

#65

Post by samhw »

lumost wrote: post #17
karolkozub wrote: post #5

I really like the idea of automated code review tools that point out unusual or suspicious solutions and code patterns. Kind of like an advanced linter that looks deeper into the code structure. With emerging AI tools like Github Copilot, it seems like the inevitable future. Programming is very pattern-oriented and even though these kinds of tools might not necessarily be able to point out architectural flaws in a co…

Consider that you may be describing a compiler. Typos are not generally a problem in statically typed languages with notable exceptions such as dictionary key lookups etc. Even without static typing, argument length verification etc. can be done with a suitable compiler. In python we are left chasing 100% code coverage in unit tests as it's the only way to be certain that the code doesn't include a silly mistake.

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

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

#66

Post by oblvious-earth »

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.

It was a meme when Zen was written, the spaces around the em dash are handled 3 different ways. Twice in the line you abbreviated, removing the joke.

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

#67

Post by atleta »

karolkozub wrote: post #5

I really like the idea of automated code review tools that point out unusual or suspicious solutions and code patterns. Kind of like an advanced linter that looks deeper into the code structure. With emerging AI tools like Github Copilot, it seems like the inevitable future. Programming is very pattern-oriented and even though these kinds of tools might not necessarily be able to point out architectural flaws in a co…

This is basically linting, i.e. code analysis. The techniques used might be more current (as they have been evolving, as you say, for pattern matching) but linting is just that: a code review tool to find usual bugs. (This is what did happen in this blog post. It wasn't looking for unusual solutions but usual mistakes.) The packaging, form of the feedback seems also different and that in itself may make a lot of difference in ease of use and thus adoption.

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

#68

Post by savant_penguin »

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.

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

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

#69

Post by oaiey »

suifbwish wrote: post #29
ianbicking wrote: post #23

Earlier quoted context omitted.

Implicit concatenation sure seems implicit to me

Implicit things are rarely nice in code for production environments. It makes bug tracing and security much more complicated

This is indeed the point. Some use cases are amazing and increase quality while others are just pure evil.

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

#70

Post by wodenokoto »

oa2022 wrote: post #41
wodenokoto wrote: post #15

Earlier quoted context omitted.

The rejection notice seems completely counter intuitive to me. How is adding a plus "harder" compared to removing a foot gun? > This PEP is rejected. There wasn't enough support in favor, the feature to be removed isn't all that harmful, and there are some use cases that would become harder.

This change would break a lot of legacy code for no good reason The most common way to split a string in lines is using this concatenation formula.

But wasn't this proposal part of the move to python 3? strings where broken left and right anyway.
Post reply on HN