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

Post by stonemetal12 » Fri, Jan 07, 2022, 7:25 PM UTC

egeozcan wrote: post #141

jstx1 wrote: 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.

> Complex is better than complicated What? Something being complex is artificial, we try to avoid it. Problems can be complicated, we try to simplify them, and more complicated the problem is, we tend to develop more complex solutions. So comparing them does not make sense? Or did I always know them wrong?

Post by onphonenow » Fri, Jan 07, 2022, 7:29 PM UTC

jollybean wrote: post #16

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…

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.

Post by dragonwriter » Fri, Jan 07, 2022, 7:31 PM UTC

onphonenow wrote: post #160

hnlmorg wrote: post #126

Earlier quoted context omitted.

10 years ago I'd have agreed with you. But Perl has gone a long way in pulling back from some of that insanity while Python has been giving C++ a run for it's money in terms of features.

I'd totally agree - there's been a burst of sort of the perl style stuff (:= ?) to gain relatively small wins. ie, instead of for line in lines: print(line) we are supposed to be using while line := f.readline(): print(line) I've not been super impressed with this type of thing. That said, string formatting is better with f strings. They also rolled back some the forced breakage from trying to force unicode with 3 wh…

  while True:
    myvar = get_it()
    if not ok(myvar):
      break
    # code that uses myvar

  while ok(myvar := get-it()):
    # code that uses myvar

Post by atleta » Fri, Jan 07, 2022, 7:33 PM UTC

oaiey wrote: post #116

atleta wrote: post #80

Earlier quoted context omitted.

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

Unfortunately no irony. I come from a programming platform (C#) where productivity is a key element of language design. I highly doubt that Anders Heijlsberg would have accepted such a error prone concept like a literal free implicit operator on a key type like strings.

Post by _dain_ » Fri, Jan 07, 2022, 7:36 PM UTC

tus666 wrote: post #112

Alternative title: 5% of Python repos has inadequate test coverage.