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

151–160 of 339 posts

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

#151

Post by bilalq »

deathanatos wrote: post #123
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.

They ran their static analyzer over a sample of GH repos. They chose 666 as the number for their sample size. That's all.

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

#152

Post by JasonFruit »

solox3 wrote: post #60
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.

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 suspect this comment was an elaborate nerdsnipe.

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

#153

Post by wirthjason »

Ironic to see this today. I spent an hour debugging this very same issue this morning.

I was just doing some simple refactoring, changing a hard coded sting into a parameterized list of f-strings that’s filtered and joined back into a string.

I’m glad that I had unit tests that caught the problem! I couldn’t figure out why it was breaking, that comma is very devilish to spot with the naked eye. I’m surprised my linters didn’t catch it either. Maybe time to revisit them.

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

#154

Post by lanstin »

kazinator wrote: post #140
NoahTheDuke wrote: post #131

Earlier quoted context omitted.

> Another one is having to import everything you use. The alternative is what exactly? Have the entire standard library exposed at once? Make all modules create non-conflicting names for exported objects, so that the json parse function has to be called json_parse and the csv parse function has to be called csv_parse? Seems less than ideal to me.

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…

It lets you debug. E.g. if they have made a file called cvs.py in the same directory, then print (cvs.__file__) will show you this. If they have some weirdly screwed up paths with multiple pythons installed and multiple copies of the modules etc., same.

I will not Go lang has the same feature carried forward from C. It helps a lot in the reading code side of the code lifecycle. And Go compiler makes you keep the imports up to date, which is good.

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

#155

Post by lanstin »

kazinator wrote: post #71
tgv wrote: post #51

Earlier quoted context omitted.

The difference is: in C, it's pretty unlikely someone wants to add strings. I suppose it's even illegal in the later C versions.

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…

Interesting. Arguably tho this shows how C is aging. I find that PRIx32 a bit ugly.

Although I just had a (logging) use case in go where I missed cpp macros - wanted the log statement to get something from the file and just had to pass it in as another parameter.

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

#156

Post by fault1 »

jofer wrote: post #115
jstx1 wrote: post #94

Earlier quoted context omitted.

But only one of them is recommended - the one that makes less sense.

How is working with figure and axes objects the one that makes less sense? Is it really that crazy do set up a figure, axes on that figure, and plot on the axes, returning an artist object for each plotting command?

one is more or less based on matlab's plotting procedures, the other is an attempt at a cogent implementation of a OOP implementation. However, the OOP paradigm just doesn't seem very good for plotting.

Personally, I like plotting in R way better than in python. It has a lot better developer UX.

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

#157

Post by skitter »

ErikCorry wrote: post #107
atleta wrote: post #80

Earlier quoted context omitted.

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code). The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between ("foo" "bar", "baz") and ("foo", "bar", "baz")

They still tend to differentiate between 2- and 3 element tuples (but I agree that the implicit concatenation is problematic).

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

#158

Post by ReleaseCandidat »

ErikCorry wrote: post #103
ReleaseCandidat wrote: post #92

Earlier quoted context omitted.

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

Or := for declaration like Go and Toit

Yes, or another symbol instead of `=` for assignment, like `<-` (F#)

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

#159

Post by atleta »

ErikCorry wrote: post #107
atleta wrote: post #80

Earlier quoted context omitted.

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code). The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

In most languages an array with 3 elements has the same type as an array with 2 elements so the type system isn't going to warn you about the difference between ("foo" "bar", "baz") and ("foo", "bar", "baz")

Fair enough. I was only thinking about the str vs tuple case. So when you have 2 elements in the parenthesis.

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

#160

Post by onphonenow »

hnlmorg wrote: post #126
webmaven wrote: post #118

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

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 which made a big difference. 3.3 added back u''

Lots of good cleanups lstrip vs removeprefix etc.

Underscores in numeric literals (10000000 vs 10_000_000)

So lots of good stuff still landing.

Post reply on HN