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

31–40 of 339 posts

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

#31

Post by thaumasiotes »

mikepurvis wrote: post #22
tyingq wrote: post #6

Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 Is there usually enough context for a linter to make an educated guess?

I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator. I'm pretty surprised that issue was so flippantly closed.

> I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator.

Maybe as a matter of linting. As a matter of language design, I think + for string concatenation is a big mistake; using different symbols for numeric addition and string concatenation is something Perl got right.

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

#32

Post by thrdbndndn »

routerl wrote: post #3

tl;dr: Python concatenates space separated strings, so ['foo' 'bar'] becomes ['foobar'], leading to silent bugs due to typos. I've been bitten by this one at work, and can't help but think it is an insane behaviour, given that ['foo' + 'bar'] explicitly concatenates the strings, and ['foo', 'bar'] is the much more common desired result. edit: This also applies to un-separated strings, so ['foo''bar'] also becomes ['f…

I luckily never accidently used this space-concatenation thing, but I've been bitten by the fact a=(1) doesn't create 1-element tuple multiple times in my early days learning Python.

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

#33

Post by oaiey »

ErikCorry wrote: post #14
oaiey wrote: post #12

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

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

While I agree, this is somehow something I expect. Implicit string concatenation without operator or function around it sounds just like a terrible idea. It breaks the basic syntax concept of `foo X bar`. On the other hand it is probably very handy with DSLs and things like that.

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

#34

Post by colpabar »

oaiey wrote: post #12

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

I was going to comment something like "who would even use this?" and then I remembered that I have in fact used that feature :) It's a somewhat "nice" way to write long strings and keep the code from getting too wide. I never did it inside an array, but I found breaking up a long string into smaller ones and wrapping them in parens without a comma was convenient, for things like error messages.

But that's just what comes with a hyper flexible language like python. You can do lots of things in lots of different ways, but you can also screw things up just as easily, and your IDE won't tell you because technically it's valid code.

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

#35

Post by rikatee »

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…

yeah something like sonarqube or https://codereview.doctor (if you use GitHub)

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

#37

Post by jstx1 »

ErikCorry wrote: post #14
oaiey wrote: post #12

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

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

That’s a complaint against the entire type system, nothing to do with misspelling.

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

#38

Post by version_five »

ErikCorry wrote: post #14
oaiey wrote: post #12

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

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

I dont think that's the same kind of thing. Your example is a tradeoff that anyone who uses a language that doesn't require explicit variable declaration faces, and it's pretty tough to argue such languages really shouldn't exist.

Missing an operator resulting in explicit behavior is much more subtle and not even obvious behavior. For those who use python, it is worse.

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

#39

Post by obua »

ReleaseCandidat wrote: post #25
ErikCorry wrote: post #14

Earlier quoted context omitted.

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

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

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

#40

Post by ReleaseCandidat »

mikepurvis wrote: post #22
tyingq wrote: post #6

Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 Is there usually enough context for a linter to make an educated guess?

I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator. I'm pretty surprised that issue was so flippantly closed.

The PR has been merged (for lists and tuples and sets only).

https://github.com/PyCQA/pylint/pull/1655

Post reply on HN