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

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

#251

Post by aflag » Fri, Jan 07, 2022, 11:44 PM UTC

benesch wrote: post #63

oa2022 wrote: post #41

Earlier quoted context omitted.

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.

I've never heard from Guido on this, but I've always felt that he created the print keyword in the very early days, just because it was easy and he always thought the language would be a niche small language. But, as the popularity of the language increased, the print keyword just stand out as a sore thumb and he just had to fix that.

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

#252

Post by Spivak » Fri, Jan 07, 2022, 11:45 PM UTC

housecarpenter wrote: post #250

nojs wrote: post #201

Earlier quoted context omitted.

> The most common way to split a string in lines is using this concatenation formula. Is it really? I tend to avoid it in favour of ””” or ‘\n’.join( ), because it looks like a mistake. Triple quotes are kind of annoying if the string is indented, but you can just not indent the string to avoid the whitespace.

I use it, personally. The other two options I find too aesthetically displeasing: not indenting the string looks bad when it's within an indented block of code, and using join and putting the strings in a list is just too much boilerplate. I will use """ if I don't care about the extra space put at the start of each line by the indentation.

I think you want textwrap.dedent

https://docs.python.org/3/library/textwrap.html#textwrap.ded...

or inspect.cleandoc.

https://docs.python.org/3.8/library/inspect.html#inspect.cle...

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

#253

Post by einpoklum » Fri, Jan 07, 2022, 11:51 PM UTC

I wonder how many of those 666 have syntax bugs which are _difficult_ to locate using code analysis tools, because they are legit in themselves and you need to know what the author meant to make the call.

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

#254

Post by [deleted] » Fri, Jan 07, 2022, 11:53 PM UTC

Spivak wrote: post #252

housecarpenter wrote: post #250

Earlier quoted context omitted.

I use it, personally. The other two options I find too aesthetically displeasing: not indenting the string looks bad when it's within an indented block of code, and using join and putting the strings in a list is just too much boilerplate. I will use """ if I don't care about the extra space put at the start of each line by the indentation.

I think you want textwrap.dedent https://docs.python.org/3/library/textwrap.html#textwrap.ded... or inspect.cleandoc. https://docs.python.org/3.8/library/inspect.html#inspect.cle...

[deleted]

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

#255

Post by jeffbee » Fri, Jan 07, 2022, 11:55 PM UTC

titzer wrote: post #36

Just to be clear, the V8 "bug" was in the test runner code and caused mis-parsing of command line options for testing for non-SSE hardware. Not exactly a critical bug.

The way the bug arrived in that test runner is interesting. It sneaked in mid-review. Possibly bugs added in the middles of code reviews are more likely to get through.

https://chromium-review.googlesource.com/c/v8/v8/+/2629465/3...

Personally, I prefer uniform lists with leading commas, because it's easier to add and remove lines for later, inevitable refactoring. For example, I prefer:

  things = [
    'foo'
  , 'bar'
  , 'baz'
  ]

This drives some people crazy, but I think it's the One True Way.

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

#256

Post by wruza » Fri, Jan 07, 2022, 11:57 PM UTC

ReleaseCandidat wrote: post #61

obua wrote: post #39

Earlier quoted context omitted.

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

I left python around the times of 2/3 drama, are nonlocal and global not there anymore?

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

#257

Post by aflag » Fri, Jan 07, 2022, 11:59 PM UTC

gabagool wrote: post #209

andi999 wrote: post #188

Earlier quoted context omitted.

And still no expressive switch/case statement, breaking out of loops and ending scripts early (for explorative programming).

>no expressive switch/case statement match/case (not a drop in switch statement) >breaking out of loops break >ending scripts early (for explorative programming) exit() or sys.exit()

I think by breaking out of loops they meant breaking out of nested loops.

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

#258

Post by Subsentient » Sat, Jan 08, 2022, 12:00 AM UTC

Interesting. I've hit this bug before, but not often in Python as far as I can remember. I guess if I need a huge list of something, I'm more likely to look to a dict than use a list with normal indexes.

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

#259

Post by wruza » Sat, Jan 08, 2022, 12:01 AM UTC

oaiey wrote: post #33

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.

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.

Not so much DSLs, it's probably something as banal and ancient as

  usage = (
    'usage: foo [options] filenames...\n'
    '  -f force concatenation\n'
    '  -c for convenience\n'
  )
  print usage

Edit: forgot to add parentheses

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

#260

Post by aflag » Sat, Jan 08, 2022, 12:08 AM UTC

jeffbee wrote: post #255

titzer wrote: post #36

Just to be clear, the V8 "bug" was in the test runner code and caused mis-parsing of command line options for testing for non-SSE hardware. Not exactly a critical bug.

The way the bug arrived in that test runner is interesting. It sneaked in mid-review. Possibly bugs added in the middles of code reviews are more likely to get through. https://chromium-review.googlesource.com/c/v8/v8/+/2629465/3... Personally, I prefer uniform lists with leading commas, because it's easier to add and remove lines for later, inevitable refactoring. For example, I prefer: things = [ 'foo' , 'bar' , 'b…

Isn't

  things = [
    'foo',
    'bar',
    'baz',
  ]

even better? In your case, if you want to add something to the beginning of the list you'll have to modify two lines.