Live data from Hacker News

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

codereviewdoctor.medium.com

291–300 of 339 posts

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

#292

Earlier quoted context omitted.

I love how simple and forgiving Python is for small projects. The "trailing comma creates a tuple" situation comes out of, as far as I can tell, a desire to create maximally convenient syntax in the scenarios where tuples are intended. I think that's great for small code! I just wish that the core team would take that same zeal for a "pythonic" experience with small code and use it to develop more scaled-up systems f…

The "trailing comma creates a tuple" bug actually comes from a disconnect between what people think defines a tuple (parenthesis) and what really does (comma). I always put parenthesis around a tuple for clarity.

whats the reason for allowing like

foo,

to be a tuple? why not make this a syntax error? is there a use for single value tuples?

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

#293
post #241
post #99

Earlier quoted context omitted.

The lack of a static type-system is IMO what makes these one-character mistakes very annoying. The compiler can't tell you something is wrong, so you're just left to figure out why things are broken, just to realize it was the smallest of typos.

C lets me do this, and doesn't say much about it. char ch_arr[3][10] = { "uno", "dos" "tres" };

On the other hand a good type system doesn't:

    # let ch_arr = [
      "uno";
      "dos"
      "tres";
    ];;
    Error: This expression has type string
           This is not a function; it cannot be applied.

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

#294
post #179

Earlier quoted context omitted.

I love how simple and forgiving Python is for small projects. The "trailing comma creates a tuple" situation comes out of, as far as I can tell, a desire to create maximally convenient syntax in the scenarios where tuples are intended. I think that's great for small code! I just wish that the core team would take that same zeal for a "pythonic" experience with small code and use it to develop more scaled-up systems f…

If you use mypy (as anyone should for any non-hobby Python usage) then Python has one of the strongest type systems available. Optional types, generics, "Any" escape hatches, everything you could want.

Would mypy have caught any of the issues highlighted in the article?

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

#295
A lot of people are criticising dynamic typing for this.

It doesn't seem to have anything to do with typing discipline.

    words = (
        'yes',
        'correct',
        'affirmative'
        'agreed',
     )
Would be a tuple (immutable list) of strings, while

    words = (
        'yes',
        'correct',
        'affirmative',
        'agreed',
     )
would also be a tuple of strings.

If haskell had for some reason decided to have the same syntax sugar, it also would have caused an issue.

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

#296

The high-level goals of python end up creating these little syntactic landmines that can get even experienced coders. My personal nomination for the worst one of these is that having a comma after a single value often (depending on the surrounding syntax) creates a tuple. It's easy to miss and creates maddening errors where nothing works how you expect. I've moved away from working in Python in general, but I think t…

I think automatic string concatenation and singleton tuples were not introduced according to some high-level goal. They are just historical baggage. Automatic string concatenation comes from C, and the singleton tuple syntax probably just seemed like a good idea at first. In hindsight, singleton tuples are not common or useful enough to deserve their own syntax. If the way to create them was something like this: t =…

One place where singleton tuples used to be common is with the old "%"-formatting, specifically in the case where there is a single argument and its value might be a tuple:

    x = (1,2,3)
    #print("the value of x is %s" % x)   # breaks if x is a tuple
    print("the value of x is %s" % (x,)) # works even if x is a tuple
There is a readable way to create singleton tuples, without the sneaky trailing comma or a new function like tuple.single:

    tuple(["hello"])
The square brackets can be slightly annoying. I recall writing the following function to omit them:

    def tup(*args):
        return tuple(args)
This basically lets you use the usual tuple syntax, just prefixed with the word "tup". The advantages are that you don't need a trailing comma for singleton tuples, and it's more obvious that a tuple is being created (it can be difficult to distinguish between tuple literals and parentheses used for grouping in a complex expression).

I am reminded of a somewhat similar issue with empty set literals: {1,2} is a set, {1} is a set, but {} is a dict. The way to create empty sets is using set().

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

#297
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…

It's further evidence that the Illuminati intentionally put these typo bugs there to destabilize the global order.

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

#298
post #201
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.

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

Both of your solutions are great but don't fully cover the use case. They are useful for multiline strings, but implicit concatenation is also often used to break long strings that may not have newlines.

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

#299
post #241

Earlier quoted context omitted.

C lets me do this, and doesn't say much about it. char ch_arr[3][10] = { "uno", "dos" "tres" };

On the other hand a good type system doesn't: # let ch_arr = [ "uno"; "dos" "tres"; ];; Error: This expression has type string This is not a function; it cannot be applied.

This is not a good type system. It's a bad language where you can invoke functions without parentesis

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

#300
post #296

Earlier quoted context omitted.

I think automatic string concatenation and singleton tuples were not introduced according to some high-level goal. They are just historical baggage. Automatic string concatenation comes from C, and the singleton tuple syntax probably just seemed like a good idea at first. In hindsight, singleton tuples are not common or useful enough to deserve their own syntax. If the way to create them was something like this: t =…

One place where singleton tuples used to be common is with the old "%"-formatting, specifically in the case where there is a single argument and its value might be a tuple: x = (1,2,3) #print("the value of x is %s" % x) # breaks if x is a tuple print("the value of x is %s" % (x,)) # works even if x is a tuple There is a readable way to create singleton tuples, without the sneaky trailing comma or a new function like…

[deleted]
Post reply on HN