We fixed f-string typos in popular Python repos
highertier.com
We fixed f-string typos in popular Python repos
1–10 of 154 posts
Re: We fixed f-string typos in popular Python repos
#2No post body was provided.
Re: We fixed f-string typos in popular Python repos
#3> For science you can see the reactions here.
That link seems to be broken: https://github.com/issues?q=is%3Aissue+author%3Acode-review-...
I was actually surprised to read that people would ignore or be annoyed by a bot raising a valid PR that can be easily merged after a quick glance. What would be the reason for that?
Re: We fixed f-string typos in popular Python repos
#4> For science you can see the reactions here. That link seems to be broken: https://github.com/issues?q=is%3Aissue+author%3Acode-review-... I was actually surprised to read that people would ignore or be annoyed by a bot raising a valid PR that can be easily merged after a quick glance. What would be the reason for that?
I expect to see the entire gamut of possible reactions with a sufficient number of bot PRs. But in looking at 10 of them at random, I didn't find a single "negative response."
(I don't think ignoring it is invalid or wrong by any means, given there's so many reasons one might not engage in a timely manner, or at all, in the issues section or PRs. I don't monitor my repos issues because I just don't feel interested in supporting my code. Feel free to fork or ignore!)
Re: We fixed f-string typos in popular Python repos
#5> For science you can see the reactions here. That link seems to be broken: https://github.com/issues?q=is%3Aissue+author%3Acode-review-... I was actually surprised to read that people would ignore or be annoyed by a bot raising a valid PR that can be easily merged after a quick glance. What would be the reason for that?
What I've found from doing similar types of changes.
1. It's hard to explain the impact to the application of the current problem. Thus it looks like a theoretical issue
2. Sometimes people rely on the bug for their code to work
3. Surprise work can be poorly received (ie: not the current priority)
Re: We fixed f-string typos in popular Python repos
#6So they checked 666 python repositories and fixed bugs in 69 of them. Interesting choice of numbers.
Re: We fixed f-string typos in popular Python repos
#7I find it ironic that the article points out that relying on error from humans to find errors is something of a hit or miss proposition and suggests that automating error finding is an appropriate course instead of making it less likely to make the error in the first place.
For example, I wonder how many errors would have been found if the definition of a format string was the default? That is, how many times would people have written something like "hello {previously-defined-variable}" and not meant to substitute the value of that previously defined variable at runtime?
Re: We fixed f-string typos in popular Python repos
#8No post body was provided.
Re: We fixed f-string typos in popular Python repos
#9> > We may be looking too deep into this but it seems like many developers think when string concatenation occurs it’s enough to declare the first string as an f-string and the other strings are turned into f-strings by osmosis. It doesn’t. We’re not suggesting this is the case for all developers that accidentally did this error, but interesting nonetheless.
I highly doubt that people believed that f-strings worked this way. Far more likely is that, for example, the expression started as one line, then got split onto two, or some such similar scenario.
Re: We fixed f-string typos in popular Python repos
#10> For science you can see the reactions here. That link seems to be broken: https://github.com/issues?q=is%3Aissue+author%3Acode-review-... I was actually surprised to read that people would ignore or be annoyed by a bot raising a valid PR that can be easily merged after a quick glance. What would be the reason for that?
Automated checking of potential bugs in f-strings is hard. There are lots of false positives. You can see some discussion around this kind of rule in pylint [0]. At the end of the day, the choice to run automated linting tools on a repo is up to the maintainers. Autogenerating PRs like this is incredibly noisy and comes off to me as a blatant advertisement for their "code review doctor" product.