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

41–50 of 154 posts

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

#41

Post by noobermin »

fareesh wrote: post #24

I like python although I don't use it too often. Would it be unfairly critical of me to say that this is the outcome of a bad design choice? Ideally languages should be designed in a way that a bug like this which is so widespread and easy to create, should be caught via some mechanism, either linting or some part of the process.

The f-strings are a recent (may be not so recent now) addition to the language, so all the errors stem from it being "new" where people's reflexes / carefulness hasn't adjusted to them yet.

I think in addition to the suggestion for linters, updating IDE/editors to incorporate them would help. Syntax highlighting is the primary reason not terminating strings isn't that common of an error anymore, coloring it differently than a normal string might help (or may be it would make things ugly, I don't know).

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

#42

Post by groestl »

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…

I think what's happening is that people assume there's type coercion going on here.

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

#43

Post by groestl »

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

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

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

#44

Post by aib »

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…

> where is the f-string described as suboptimal?

I guess it's implicit in that f-strings, as arguments, will be evaluated before the logging function can even run whereas `debug("...", heavy_obj)` will avoid a potentially expensive `str(heavy_obj)` (or whatever the string conversion warrants.)

As for raiseExceptions, I'm not sure it's for optimization. It looks like an old sanity check for bad logging configurations.

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

#45

Post by vitus »

dekhn wrote: post #26
vitus wrote: post #13

Earlier quoted context omitted.

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!)

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 are a good idea." I have no opinions on whether the code should be clearer, but that doesn't change the validity of the reaction.

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

#46

Post by dekhn »

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…

I do think the question of "how should bots that do static analysis work" is an important one, but in the meantime, people are gonna bot and repo managers are gonna complain.

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

#47

Post by GeorgeTirebiter »

groestl wrote: post #43
_8j50 wrote: post #37

Earlier quoted context omitted.

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

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.

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

#48

Post by kgeist »

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?

>Would you expect that a user input like "{secret} please" is interpolated?

That's basically what the recent log4j security vulnerability was all about. "Helpfully" interpolating logs by default.

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

#49

Post by Sohcahtoa82 »

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?

Adding that behavior would break existing code that uses str.format, and Python tries to avoid breaking code between minor releases.

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

#50

Post by Someone »

swatcoder wrote: post #19
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.

Not much overhead, I would think. We’re talking about literal strings in source code, not strings in general. It’s not much work to check those.

One thing that it would break is that strings read from files would be treated differently from those in source code, even those read from files that logically “belong” to the application (say config file)

I don’t think that’s an issue, though.

Also, in Swift "\(foo)" does string interpolation. I haven’t seen people complain it leaks data or makes Swift slow (but then, it’s not fast at compiling at all because of its rather complicated type inference)

Post reply on HN