Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fixed f-string typos in popular Python repos

highertier.com

Post reply on HN
Print view View original

11–20 of 154 posts

Re: We fixed f-string typos in popular Python repos

#11

Post by HL33tibCe7 »

readthenotes1 wrote: post #7

I 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 p…

That’s not really a feasible solution in Python because that change would break a load of existing code.

Re: We fixed f-string typos in popular Python repos

#12

Post by zamadatix »

dewey wrote: post #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?

In reactions they conveniently left out "false positives we still hadn't weeded out". On top of that it can be annoying to have bots making trivial PRs in their own format when you've got a well defined process for it. Lastly it was basically spamming an ad link for the service at the end of the PR comment - even if the other issues didn't come up it's not always well received to do that.

Looking at 1 bot it doesn't sound bad, when you have everyones bot doing this kind of stuff it can quickly become more of a nuisance than a help.

Re: We fixed f-string typos in popular Python repos

#13

Post by vitus »

Waterluvian wrote: post #4
dewey wrote: post #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?

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…

Some negative reactions:

https://github.com/mitmproxy/mitmproxy/issues/5285

https://github.com/Qiskit/qiskit-terra/issues/7981

https://github.com/beetbox/beets/issues/4340

I do think those concerns are legitimate. (I also think more tooling is a good thing!)

Re: We fixed f-string typos in popular Python repos

#14

Post by cinntaile »

dewey wrote: post #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?

https://github.com/Qiskit/qiskit-terra/pull/7982

That guy was not happy. I do agree that it's basically advertising and that's annoying.

Re: We fixed f-string typos in popular Python repos

#15

Post by jjoonathan »

dewey wrote: post #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?

You're assuming that the PR is valid, but a maintainer can't make that assumption. They have to do the thankless work to figure out the context and handle the fallout if they get it wrong. Let's look at who wins:

    * Small benefit to bot creator
    * Tiny benefit to project
    * Modest cost to maintainer
Waves of low-effort resume-padding commits are already a thing. Not a big problem, but bots clearly have the potential to multiply the small problem into a big problem.

I'm still open to the idea that bots could be a net win, because most projects really do have heaps of small simple mistakes lying around. I'm sympathetic to the maintainers though. They always seem to get the short end of the stick.

Re: We fixed f-string typos in popular Python repos

#16

Post by macspoofing »

readthenotes1 wrote: post #7

I 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 p…

>...and suggests that automating error finding is an appropriate course instead of making it less likely to make the error in the first place.

You can't fix the syntax and standard lib of the language. It is what it is. Similarly, how many bugs would you prevent if Python had compiler support to catch those types of syntax (and type) errors.

Re: We fixed f-string typos in popular Python repos

#17

Post by memco »

The article links to some docs for the logging module here: https://docs.python.org/3/howto/logging.html#optimization asserting that f-strings are less optimal but the docs do not say that they do not optimize our the expression evaluation of f-strings: only that the logging module tried to perform evaluation as late as possible: where is the f-string described as suboptimal?

Relatedly the logging optimization suggests setting: raiseExceptions to false for production logging code: where is that set? On the logger, handler or something else?

Re: We fixed f-string typos in popular Python repos

#18

Post by VWWHFSfQ »

dewey wrote: post #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?

Because this is basically just PR spam

Re: We fixed f-string typos in popular Python repos

#19

Post by swatcoder »

readthenotes1 wrote: post #7

I 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 p…

To be fair, your suggestion might make for a more resilient default, but it's also a great way to leak data and add overhead for the default case. There are tradeoffs.

Re: We fixed f-string typos in popular Python repos

#20

Post by mschuster91 »

HL33tibCe7 wrote: post #11
readthenotes1 wrote: post #7

I 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 p…

That’s not really a feasible solution in Python because that change would break a load of existing code.

So what? Raise a deprecation notice, treat it as a fatal error in two or three years and that's it. PHP has been doing this for years now.
Post reply on HN