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

Post by kazinator » Fri, Jan 07, 2022, 6:19 PM UTC

tgv wrote: post #51

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 difference is: in C, it's pretty unlikely someone wants to add strings. I suppose it's even illegal in the later C versions.

  uint32_t x = 0;

  printf("x = " PRIx32 "\n", x);

  printk(KERN_EMERG "%s: temperature sensor indicates fire!", dev->name);
                   ^ must not have comma here

Post by ReleaseCandidat » Fri, Jan 07, 2022, 6:19 PM UTC

shultays wrote: post #59

colpabar wrote: post #34

Earlier quoted context omitted.

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…

You could have the same behavior by enforcing + operation in between mylongstring = "hello" + "world" No idea if python's way of indentations allows this but sounds like it should

    mylongstring = ("hello" +
       "world")

      mylongstring = ("hello"
       "world")

Post by lumost » Fri, Jan 07, 2022, 6:21 PM UTC

samhw wrote: post #65

lumost wrote: post #17

Earlier quoted context omitted.

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

Post by justsomehnguy » Fri, Jan 07, 2022, 6:22 PM UTC

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…

   @"
  here strings in PS are fine for this purpose and 
   even allows whitespace anywhere            
    but because of the latter you can't indent it    
     with your other code   
 "@ -split "`r`n" | % {'{0}' -f $_ }
     here strings in PS are fine for this purpose and 
      even allows whitespace anywhere            
       but because of the latter you can't indent it    
        with your other code   

Post by oaiey » Fri, Jan 07, 2022, 6:22 PM UTC

jve wrote: post #27

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.

I checked those those 11 links to issues for major software. 10 bugs were actually in tests...