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

51–60 of 154 posts

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

#51

Post by klyrs »

vitus wrote: post #45
dekhn wrote: post #26

Earlier quoted context omitted.

I looked through all three. The first isn't really a complaint because the bot acted in good faith and found an error. In the second one they complained abiout a missing unsubscribe link (reasonable) and in the third one, the author should update their code so it doesn't create a variable named path, then a non-f-string that includes "{path}". I had to stare at the author's comment that it was a false positive for qu…

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.

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

#52

Post by f7fg_u-_h »

> After creating 69 pull requests the reaction ranged from:

> Annoyance that a bot with no context on their codebase was raising pull requests. A few accepted the bugs were simple enough for a bot to fix and merged the pull request, but a few closed the pull requests and issues without fixing. Fair enough. Open source developers are busy people and are not being paid to interact with what they think it just a bot. We’re not entitled to their limited time.

> Neutral silence. They just merged the PR.

> Gratitude. “thanks” or “good bot”.

I appreciate their self awareness about responses from maintainers.

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

#53

Post by mulmen »

swatcoder wrote: post #31
mschuster91 wrote: post #20

Earlier quoted context omitted.

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.

As someone who would like to be working on new, interesting things in 2-3 years rather than bringing old code into conformance with breaking changes, this attitude captures a worrisome trend in development. On the one hand, it's great that we have platforms that innovate and improve and harden over time, but we're also facing a development culture where more and more time is spent servicing package/platform/language/…

One person’s “new interesting thing” is another person’s “breaking change”.

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

#54

Post by johnny_castaway »

HL33tibCe7 wrote: post #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 t…

This may be also caused by confusing syntax highlighting in some editors, for example in VSCode [1]

The variable in the second string gets highlighted (with slightly different color, but still) because it would still work with `str.format()`. GitHub doesn't seem to do this.

[1] https://imgur.com/a/9KGWVG0

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

#57

Post by masklinn »

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.

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

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

#58

Post by HL33tibCe7 »

_8j50 wrote: post #37
HL33tibCe7 wrote: post #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 t…

You'd be surprised, people who expect python to be "smart" and "figure it out" might think that way.

As a beginner, maybe. But this is code in some of the biggest open-source Python repos in existence. Probably written by someone with a reasonable level of Python expertise.

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

#59

Post by ArchOversight »

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.

Because in some cases it is not desired, if for example the string is used in something that expands it further down the line (think SQL injection potential).

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

#60

Post by masklinn »

bobbiechen wrote: post #21
memco wrote: post #17

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 sugges…

I was also confused by the expression evaluation thing. Reading between the lines, it seems like logger.debug("hello %s", foo) may be better than logger.debug(f"hello {foo}") in the case when loglevel is higher than debug. In the first version, the final string does not have to be computed, while in the second version, we might construct the string and then do nothing since the loglevel is excluded.

That's exactly it.

Although this becomes more complicated because printf-style string formatting is not free (though it's the cheapest of all methods save fstrings if I remember correctly), and because python does not support lazy parameters if `foo` is a non-trivial expression odds are good it will far outcost either formatting.

Post reply on HN