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

61–70 of 154 posts

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

#61

Post by mhils »

klyrs wrote: post #51
vitus wrote: post #45

Earlier quoted context omitted.

I will point out that in the first two issues, the repo owners also edited the initial report with something along the lines of "removed ad". I disagree that the first isn't a complaint -- the owner stated that this behavior isn't appreciated but decided to let it slide because the issue was valid. In the third issue, the owner also explicitly stated: "I don't think bots posting unsolicited static analysis results ar…

The bot-account's (apparently human-written) reply of "you're very welcome" to the complaint in the third issue is downright dismissive of the problem and kinda passive aggressive. While it seems that the bot did good work overall, the human(s) handling edge cases need work.

We've blocked the bot after their script malfunctioned and they opened a second issue with exactly the same text (https://github.com/mitmproxy/mitmproxy/issues/5286).

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

#62

Post by bagels »

GeorgeTirebiter wrote: post #47
groestl wrote: post #43

Earlier quoted context omitted.

Well, it's not completely unlogical. 'a' is str b'a' is bytes f'something' might be a separate f-str-type too? 1 is an int 1.2 is a float (1.2 + 1) is a float

Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? After all, we don't specifically add a type to a number like 42 or 3.14159 --- those are implicitly 'int' and 'float' types. I would use such a feature, as I always use f-strings when formatting.

Backwards compatibility for one. Code existed before fstrings that may use curly braces, and you can currently use curly braces in non fstrings without escaping them.

Might also be a performance penalty for always having to run the fstring parser.

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

#63

Post by mhils »

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 our case OPs bot did not open a PR which could have been merged quickly, but filed an issue instead.

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

#64

Post by dragonwriter »

GeorgeTirebiter wrote: post #47
groestl wrote: post #43

Earlier quoted context omitted.

Well, it's not completely unlogical. 'a' is str b'a' is bytes f'something' might be a separate f-str-type too? 1 is an int 1.2 is a float (1.2 + 1) is a float

Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? After all, we don't specifically add a type to a number like 42 or 3.14159 --- those are implicitly 'int' and 'float' types. I would use such a feature, as I always use f-strings when formatting.

If all strings with what looks like format specs are implicitly f-strings, how do you use reusable template strings, which use the same basic internal syntax, for formatting?

f-strings, like r-strings, have uses, but, like r-strings, I wouldn't want to replace plain strings with them.

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

#65

Post by GeorgeTirebiter »

masklinn wrote: post #57
GeorgeTirebiter wrote: post #47

Earlier quoted context omitted.

Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? After all, we don't specifically add a type to a number like 42 or 3.14159 --- those are implicitly 'int' and 'float' types. I would use such a feature, as I always use f-strings when formatting.

> Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? Because it would break existing strings containing braces, such as those used with `str.format`, or string.Template, or literal Jinja templates, ...

Yes, my use case was "I always use F-strings" so these other breakages could not occur, by definition.

I suppose it's not that much of a problem to run a program to preprocess source and add in the F

But.. Python has a history of introducing new features that break old ones. That seems to me a balance between backward compatibility and future goodness.

the "from future import auto-fstring" construct could do it...

And, as for having to run the f-string parser: yes, but only once on static strings, which are most of them.

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

#66

Post by boxed »

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…

This is how strings work in swift. It's a much superior system imo.

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

#67

Post by boxed »

MauranKilom wrote: post #23
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…

I don't think this makes sense. Plain strings and format strings are not interchangeable, and using one where the other was meant is probably a bug. Would you expect that a user input like "{secret} please" is interpolated? If so, we hopefully agree that this would blow major security holes into any python script processing untrusted user input. And if not... Why not?

Look up how this works in Swift. They only have one string. No raw strings or f strings. Yet they have all the power of all three python string types and less syntax. It's very nice.

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

#68

Post by rikatee »

mhils wrote: post #61
klyrs wrote: post #51

Earlier quoted context omitted.

The bot-account's (apparently human-written) reply of "you're very welcome" to the complaint in the third issue is downright dismissive of the problem and kinda passive aggressive. While it seems that the bot did good work overall, the human(s) handling edge cases need work.

We've blocked the bot after their script malfunctioned and they opened a second issue with exactly the same text ( https://github.com/mitmproxy/mitmproxy/issues/5286 ).

klyrs was right about the reply from me (a dev behdind Code Review Doctor) being dismissive in the issue. I apologise for that.

FWIW my reaction was classic "expectations not meeting reality": weeks of work to do (what I thought) was a mutually beneficial helpful thing. I was naively not expecting non-positive responses and was ill prepared when you raised valid concerns I had not considered.

Again, I am working on that and sorry I was passive aggressive to you.

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

#69

Post by mhils »

We've been one of 666 repos, and I'm not too happy of having our repo used as advertising space. Some thoughts:

- I'm happy to receive fix-a-typo PRs from human users. In this case the other side demonstrated that they care by putting in a bit of manual effort, and a small PR often paves the way towards larger contributions. I also know that open source beginners get really excited about their first small contributions, and I'm honestly happy to support that.

- In contrast, the marginal effort for bot PRs is ~0. It's very easy to generate a small amount of work for a lot of people, and the nice side effect is that the bot's platform is advertised everywhere. As a maintainer, I have never given consent to this and I have no choice to opt out.

We are very happy users of some GitHub bots, but I feel it needs to be an active adoption decision by the maintainer. If you want to pitch me your service you may send me an unsolicited email, but don't use our public space to advertise your product without asking.

Edit: I don't want to be too harsh to OP here - at least they pointed out a small but valid issue in our case. I very much appreciate their apology at https://news.ycombinator.com/item?id=31210245

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

#70

Post by rikatee »

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…

what's also ironic is I left an easter egg in the code sample for how we downloaded the list of repositories and no one has noticed it yet.
Post reply on HN