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

41–50 of 339 posts

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

#41

Post by oa2022 »

wodenokoto wrote: post #15
arusahni wrote: post #8

The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/

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.

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

#42

Post by Wowfunhappy »

arusahni wrote: post #8

The removal of implicit string concatenation was proposed for Py3k[1], but was rejected. [1] https://www.python.org/dev/peps/pep-3126/

Does Python support the concept of allowing code to opt in to new safety features? I can understand rejecting something like this for the sake of legacy compatibility (something Python has abandoned too readily in the past), but it seems like an option—or maybe even a default—might be nice.

I suppose this is also something you could catch with a linter?

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

#43

Post by rikatee »

prepend wrote: post #4

This seems like not a big deal. It’s a common mistake and is in 5% of repos but it’s not causing major damage. And there’s no evaluation of importance as to whether these instances are in test files or non-critical code. Packages are big and can have hundreds or thousands of files. It could be that if these mattered, they would have been detected and fixed. A good example for unit tests and perhaps checking to see if…

yeah the impact varies. the sentry one seems pretty big: https://codereviewdoctor.medium.com/5-of-666-python-repos-ha...

test did not work but did not fail either, imagine being that dev maintaining the code that the test professes to cover. Imagine being the user relying on the feature that test was meant to check (if the feature under test actually broke).

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

#44

Post by edflsafoiewq »

kazinator wrote: post #18

Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…

The Python certainly looks nicer though.

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

#45

Post by voltagedivider »

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.

Isn't that common for all/most languages that don't require explicit typing?

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

#46

Post by rileymat2 »

kazinator wrote: post #18

Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…

I like imports, it tells me what files symbols are coming from, even for built in libraries.

Maybe it is that through my work I use a half dozen languages, where it is hard to remember each in detail.

I have also worked on a javascript project where there were no imports/requires and the build process created one file. So you had to inspect the confusing build script to even know what was what.

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

#47

Post by rikatee »

bcrl wrote: post #24
jollybean wrote: post #16

Earlier quoted context omitted.

5% of 'released' software is quite a lot, more importantly it's a class of errors that definitely should not exist. This is a 'bug' in the language effectively there just isn't any real upside. Python has a few of these things, which is really sad.

It's a class of error that would be caught by even the most basic testing. A better title for the article is that 5% of 666 Python repos have typos that demonstrate the code in them that is completely untested. It doesn't matter which language it is: untested code is untested code in any language.

unfortunately like 10% of the bugs were in the tests themselves. e.g., the sentry one https://codereviewdoctor.medium.com/5-of-666-python-repos-ha...

the tests are only as good as the code they're written with, and as good as the code review process they were merged under.

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

#48

Post by oaiey »

colpabar wrote: post #34
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 c…

I completely get that. That is a very nice feature for building DSL or libraries with special needs. But it makes the overall language very dangerous.

Is this "operator" overloadable on each type in Python?

And that scares me a lot. I think I have to reevaluate my position towards Python.

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

#49

Post by shultays »

version_five wrote: post #38
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 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.

  it's pretty tough to argue such languages really shouldn't exist
Well, I agree with OP so that is at least two people. I really don't see it as a good trade.

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

#50

Post by silisili »

colpabar wrote: post #34
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 c…

Why not just use plusses? Or perhaps a join func, which would accomplish the same.

I get the use case as you described it, but it just seems like minimal effort to accomplish and have some semblance of explicit/safety.

Post reply on HN