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

121–130 of 339 posts

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

#121

Post by SomeCallMeTim »

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.

"Shouldn't exist" is too strong.

Dynamic languages that let you create a new variable via assignment shouldn't be used to create non-trivial software. How about that?

Scripting languages have a place. That place is 100% in creating quick-and-dirty scripts and tools. Or in doing some kind of one-off data transform (as is common in machine learning scenarios). Anything that has a life span of two weeks or less, or a code length of fewer than a hundred lines? Yeah, script languages rock for that.

Explicit/static typing adds vastly more value to large projects than the cost of the overhead. The fact that you can't really gain that value in Python means that Python should be relegated to quick and dirty scripts.

Same for JavaScript, Ruby, and other completely dynamic languages.

You'll note that all of these languages are getting types one way or another, meaning that there are a lot of people who do recognize their value. Though TypeScript is years ahead of the rest in the completeness and sophisticated of its type system; bugs like the comma bug detailed by OP, along with simply every JavaScript "wat" bug, simply can't happen in TypeScript in strict mode. And static types enables entire other categories of bugs to be detectable via a linter as well.

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

#122

Post by deathanatos »

ReleaseCandidat wrote: post #92
fragmede wrote: post #78

Earlier quoted context omitted.

Keywords like namespace , no; but functions and classes and modules provide for a lot of scoping opportunities.

The problem is `fop` should be `foo`: foo = 5 fop = 6 Keywords like `let` solve this problem: let foo = 5 fop = 6 # error

Not entirely:

  let foo = a();
  let foo = b(foo);
  let fop = c(foo);
  let foo = d(foo);
(Which is valid, e.g., in Rust.)

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

#123

Post by deathanatos »

bilalq wrote: post #64

The whole "666" thing really threw me off. I thought it was some Python specific term or something at first glance. They open with a sentence that mentions "5% of the 666 Python open source GitHub repositories" as though there were only 666 total open source Python GH repos. Picking a number with other fun connotations or whatever to use as a sample is fine, but without setting that context, it was kind of distractin…

Did you figure out what the context is, and if you did, would you mind spelling it out for me? I still haven't figured out what correction to make to that sentence to get it to make sense.

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

#124

Post by kazinator »

stevesimmons wrote: post #120
rileymat2 wrote: post #46

Earlier quoted context omitted.

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.

I like the explicit nature of Python's imports. And especially how I can choose the best way to indicate the sources of names in my code: import time t = time.perf_counter() import time, my_module t1 = time.perf_counter() t2 = my_module.perf_counter() from time import perf_counter as std_counter from my_module import perf_counter as my_counter t1 = std_counter() t2 = my_counter() try: from my_module import perf_count…

> import perf_counter as my_counter

Yikes; you're renaming/aliasing global identifiers! Just no.

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

#125

Post by voltagedivider »

xigoi wrote: post #76
solox3 wrote: post #60

Earlier quoted context omitted.

Notice that, in the original quote, There should be one-- and preferably only one --obvious way to do it. the author used two different ways of hyphenating (three, if you count the whole PEP 20). PEP 20 is clearly not meant to be taken as law. Nor PEP 8. Nor PEP 257. People frequently mistake "one obvious way" with "one way". There are lots of ways to iterate through something, for example, but there is really one ob…

I can think of at least 2 obvious ways to iterate through something: for loops and comprehensions.

You're right that both iterate through something but `for` loops and comprehensions aren't used as if they were interchangeable.

For example, you'll sometimes see people do bad stuff like this:

  >>> lst = []
  >>> 
  >>> [lst.append(i + i) for i in range(10)]
  [None, None, None, None, None, None, None, None, None, None]
  >>> 
  >>> lst
  [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
  >>>
When they should be doing this:

  >>> lst = []
  >>> 
  >>> for i in range(10):
  ...     lst.append(i + i)
  ... 
  >>> lst
  [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
  >>>
Or just this:

  >>> lst = [i + i for i in range(10)]
  >>> 
  >>> lst
  [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
  >>>

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

#126

Post by hnlmorg »

webmaven wrote: post #118
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.

> 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. Not in comparison to Perl, which usually has multiple ways to do anything, each 'obvious' to different sets of people (each Perl codeba…

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.

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

#127

Post by deathanatos »

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

9 out of 10, actually; the Tensorflow links are the same link.

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

#128

Post by Someone »

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…

You mean

  long %s stringnicely breaks upwith indentation and all"
? In my experience, this always gets ugly when you want to insert spaces (= about always). Do you put them at the end or at the start of each string (apart from the first or last string)

I think scala’s mkString (https://superruzafa.github.io/visual-scala-reference/mkStrin...) is the best solution, visually, for such things, but unfortunately, it would require hackers in the parser to do the concatenation at compile time, where possible.

Scala’s multiline strings look nice, too, if you want to insert newlines, except for the stripMargin thing (https://docs.scala-lang.org/overviews/scala-book/two-notes-a...)

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

#129

Post by pfisherman »

micimize wrote: post #62

For those looking to avoid this specific problem, there is a flake8 rule: https://pypi.org/project/flake8-no-implicit-concat . More broadly, the https://codereview.doctors makers are making the point that their tool caught an easy-to-miss issue that most wouldn't think to add a rule for. A bit of an open question to me how many of those there really are at the language level, but still seems like a neat project.

Ime, Black will add parenthesis to clearly and explicitly indicate a tuple where there is trailing comma. Figured this out when I made the trailing comma mistake and wondered why Black kept reformatting my code.

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

#130

Post by aylmao »

dpedu wrote: post #93
usrbinbash wrote: post #11

Literally the second item in the "Zen of Python" ( https://www.python.org/dev/peps/pep-0020/ ): Explicit is better than implicit. And yet, s = ["one", "two" "three"] will implicitly and silently do something, that is probably wrong most of the time.

Hmmm, it sounds like you're expecting "two" and "three" to be separate list elements because of some sort of implicit behavior due to being written in a list context. This is the opposite of what "Explicit is better than implicit" means. This is a list and you must explicitly place a comma when you want to start a new element in the list. Is there ever a time a new element follows a previous one and is NOT separated…

Ah yes, why would anyone expect lists' main purpose to be listing?

Sarcasm aside, I'd assume people primarily list things in between [ and ], and sometimes concatenate things in there too. The language should err on the side of doing what people expect, unless explicitly told not to.

> It seems like you're assuming behaviors from other languages would be the same in another.

Rather, I think people expect a language, especially one this big and important, to work for them, and not to be designed with unergonomic features instead.

Post reply on HN