Live data from Hacker News

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

codereviewdoctor.medium.com

231–240 of 339 posts

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

#231
post #48

Earlier quoted context omitted.

I completely get that. That is a very nice feature for building DSL or libraries with special needs. But it makes the overall language very dangerous. Is this "operator" overloadable on each type in Python? And that scares me a lot. I think I have to reevaluate my position towards Python.

It's not really an operator. It's part of the syntax of string literals. "foo" "bar" is an alternative way of writing the string literal "foobar". If foo is not a string literal, foo "bar" is invalid syntax.

Okay... So it is not a implicit operator. That is good. Some small reputation points are regained.

Thanks.

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

#232
post #133

Earlier quoted context omitted.

Yes, it is crazy. I guess this isn't really the place for it but ... From the official docs: The Figure is the final image that may contain 1 or more Axes. The Axes represent an individual plot (don't confuse this with the word "axis", which refers to the x/y axis of a plot). This is infuriatingly bad and I firmly believe that it makes sense only to people who already know how it works. There's an image, axes (this w…

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

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

#233
post #225

Earlier quoted context omitted.

It is positively not illegal in any standard verision of C since ANSI C 89. It's an essential feature used in all sorts of everyday code. C99 added printf conversion specifiers that are hidden behind macros, and idomatic usage of them relies on string catenation. uint32_t x = 0; printf("x = " PRIx32 "\n", x); where PRIx32 might expand to "%lx" (if uint32_t is the same as unsigned long in that compiler). All sorts of…

I know that. I meant that “abc” + “def” is most likely illegal (although “abc” + ‘d’ is not).

> I meant that “abc” + “def” is most likely illegal

That would be adding 2 pointers, and that's indeed illegal.

However, you can subtract them: “abc” - “def” . Now, the result is not a pointer any more, it's a ptrdiff_t (an integer type), so most compilers will warn if you try to assign that to a char *.

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

#234

Earlier quoted context omitted.

I'd totally agree - there's been a burst of sort of the perl style stuff (:= ?) to gain relatively small wins. ie, instead of for line in lines: print(line) we are supposed to be using while line := f.readline(): print(line) I've not been super impressed with this type of thing. That said, string formatting is better with f strings. They also rolled back some the forced breakage from trying to force unicode with 3 wh…

> ie, instead of > for line in lines: print(line) > we are supposed to be using > while line := f.readline(): print(line) No, we’re not. Walrus, in loops, IME, is more for replacing this pattern: while True: myvar = get_it() if not ok(myvar): break # code that uses myvar with this pattern: while ok(myvar := get-it()): # code that uses myvar

False. I have been harshly attacked here on HN for suggesting things like for line in lines - literally been called "stupid".

I'm not the only one who looked at the recommended examples of the use case here and went, huh?

https://news.ycombinator.com/item?id=17450890

Recommended new way:

  if any(len(longline := line) >= 100 for line in lines):
     print("Extremely long line:", longline)
Old way:

    for line in lines:
        if len(line) >= 100:
            print("Extremely long line:", line)
            break

I prefer the old way. These were examples in the PEP!

In your example get_it() might be better as a generator or iterable. A lot of code looks great if you push that type of thing down a bit, and sometimes memory is helped as well. Then you iterate over it, for values in get_it. This keeps python very natural. You start to get a lot of weird line noise type code with := vs the old python style which while a bit longer was basically psudo-code.

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

#235
post #30

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.

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.

Python finally ended up following Perl's TMTOWTDI motto! https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...

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

#236

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.

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.

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

#237

Earlier quoted context omitted.

Also all but 1 of the issues they found relates to test code, it seems people are a little less careful compared to functional code. Also in terms of mistakes codereviewdoctor twice linked to the same issue in their blog https://github.com/tensorflow/tensorflow/issues/53636 and raised the PR to the wrong project https://github.com/tensorflow/tensorflow/pull/53637 (I guess Tensorflow vendors Keras, easy mistake)

https://github.com/tensorflow/tensorflow/tree/0d8705c82c64df... STOP! This folder contains the legacy Keras code which is stale and about to be deleted. The current Keras code lives in github/keras-team/keras. Please do not use the code from this folder. Yeah, not the most obvious notice. The fact they didn't find the same mistake(s) in keras-team/keras (I assume they scanned, it's one of the most popular Python repo…

once tensorflow pointed to keras-team this happened

https://github.com/keras-team/keras/issues/15854

resulting in

https://github.com/keras-team/keras/pull/15876

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

#238

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’d rather a compile time error over an exception (or both), which in many cases can occur. I know mypy does this, maybe I should alias python=“mypy&&python”

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

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

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.
Post reply on HN