Live data from Hacker News

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

codereviewdoctor.medium.com

261–270 of 339 posts

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

#262
post #260

Earlier quoted context omitted.

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.

Depending on the context, yes. But sometimes you are not allowed the last comma.

ETA: Let me expand on why it's important to put the comma first. Which list is more clear to you:

    a
  , dog
  , weather
  , banana
  , b
  , car
or

  a,
  dog,
  weather,
  banana,
  b,
  car
With the leading commas, they all line up, and you can see them in a neat little row. I really prefer it especially in contexts where the trailing comma is not permitted, such as a SQL query:

  SELECT
    name
  , date
  , operation
  FROM
    stuff

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

#263
post #198

Earlier quoted context omitted.

I still don't understand why it doesn't! So I still get bit from time to time.

Presumably because parantheses don't really have anything to do with tuples, it's commas that do. Parantheses are there to help the parser group things in case of ambiguity, and to support expressions spanning multiple lines.

Since you typed it twice, I don't think it's a typo. It's parentheses not parantheses.

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

#264

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.

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

This is a scoping rule, not typing. Scoping is a mechanism of symbol resolution, i.e. what do you mean by `foo` at line N. Is it a local, an argument, a global, or addresses a symbol defined in an enclosing scope? Most languages use explicit local definitions, searching implicit ones in outer scopes bottom-up, ending at the global scope. Python was the first popular non-basic language which made implicit assignments to be local and shadowing and function-scoped:

  global x = 1
  def setx():
    if True:
      x = 2 # completely different x
    print x # prints 2, visible outside of `if`
  setx()
  print x # prints 1
This led to a funny keyword 'nonlocal', because you can't simply ignore scoping and pretend that you're BASIC in any serious program.

(To my opinion, python had a good start, but lost in the woods for no clear reason. It's a movie mutant of a language, which tried to appeal to non-programmers and somehow succeed, and then realized that non-programmers eventually become ones, and it's not hard. Now it's too late to fix this mess. End of opinion.)

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

#265

Earlier quoted context omitted.

Use \ mylongstring = "hello " \ "world " \ "my " \ "name " \ "is"*

The use of \ is discouraged in Python. From PEP8: > The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.

See I knew Python just wants to be more like lisp.

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

#266

Earlier quoted context omitted.

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.

Black rules. I love it that I don't need to have a discussion about style with anyone when Black is used on the project.

TBH I think every language should have a longer like this and teams should just apply it and never need a discussion about formatting.

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

#267

Earlier quoted context omitted.

The spaces aren't the point of the comment; rather that we can break the literal into pieces and indent those pieces without affecting the contents. In a non-strawman real exmaple with real data, of course we include all the necessary spaces in the literals. However, this bug is easy to make in C; I've seen it numerous times.

That’s preciseLy my point. This looks nice, but it’s too easy to forget tone of those spaces and to hard to spot that.

I don't know of a good design that won't lead you to make errors when you don't want the spaces. You'd need some piece of syntax which indicates whether you want a space there or not. For instance, there could be a rule that a string literal ending in non-whitespace cannot joined with a literal starting with non-whitespace:

  "foo" "bar"     // error
  "foo " "bar"    // OK
  "foo" " bar"    // OK
  "foo" "" "bar"  // OK: "" doesn't start with non-whitespace, since it's empty
  "foo" " " "bar" // OK
The nice thing about this is that it's perfectly comatible with existing C.

All we have to do is to implement a compiler warning which detects when the rule is violated.

Users who implement it have to fix situations like "foo" "bar" into "foo" "" "bar".

Probably the rules should be smarter. Some kind of tokenization concept could be at play so that gluing together two letters or digits is bad, or two punctuation tokens, but letter/number and punctuation is okay.

  "foo" "1"     // error? OK?
  "foo" "bar"   // error
  "foo" ".bar"  // OK
  "1." "2" ".3" // OK
 
  "1." ".2"     // error: punct-punct

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

#268

I can see the value of a lint (if there's a newline without a comma, warn), but concatenating strings by multiplication is the correct thing to do (since it's also used this way in mathematics of parsers). Using the plus operator to concatenate strings is just weird. Think of the usual algebraic properties these operators are supposed to have. "+" always is supposed to be commutative--so "a"+"b" = "b"+"a", if those m…

Which invertible commutative string operation would you choose for + ?

This might be nice from a math point of view, but I think users are going to be confused using "string"^3 for repetitions (instead of "string"*3). + and * make too much sense to the unwashed masses.

At any rate, explicit is better than implicit.

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

#269

Earlier quoted context omitted.

That's one way. If these things are classes in a plain old single-dispatch oop system, you can havec a json-parser and csv-parser which have parse methods. There could be packages/namespaces. So csv:parse and json:parse. These packages are standard and so they just exist; nothing to import. In Python, you cannot use anything without an import! The top-level modules (which serve as de facto namespaces) themselves are…

> This jaw-droppingly moronic. It can be slightly inconvenient but doesn’t feel moronic to me. It means that except for the built-in functions, everything can be traced to either a definition or an import. Makes tracking code much easier.

Why not import the built-in functions too? The only thing not requiring import can be import.

  from python import def  # now you can def
That should be even easier to track things; now you don't have to deal with the difficulty of def not being defined anywhere in your code. It's traced to an import, which is telling you that def comes from python, liberating you from having to know that and remember it.

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

#270
post #232

Earlier quoted context omitted.

>axes (this word alone is a crime), why so? you prefer something like axiis?

See, that's the thing: > Axes object is the region of the image with the data space. In matplotlib axes is not the plural of axis. It has its own meaning specific to the API. And at the same time it's the plural form of another word (axis) which is also relevant in this context and it sounds almost identical when pronounced.

I like the wording in the MATLAB docs (since Matlab committed the original sin, the axes/axis/figure API has been around since the late '80s, matplotlib is just a port to python):

https://www.mathworks.com/help/matlab/ref/axes.html

https://www.mathworks.com/help/matlab/ref/axis.html

https://www.mathworks.com/help/matlab/ref/figure.html

So they emphasize the cartesianess of the axes.

Post reply on HN