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

21–30 of 154 posts

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

#21

Post by bobbiechen »

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.

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

#22

Post by nimish »

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…

The "Use logging's interpolation" warning has always annoyed me. If logging is in your hot path, that might be an issue. Me f-string interpolating some info logs that run once for convenience is not.

Low value junk like this is not helpful.

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

#23

Post by MauranKilom »

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?

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

#24

Post by fareesh »

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.

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

#25

Post by bornfreddy »

mschuster91 wrote: post #20
HL33tibCe7 wrote: post #11

Earlier quoted context omitted.

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.

Also see: Python 2 => 3 hell. Nobody wants to repeat that.

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

#26

Post by dekhn »

vitus wrote: post #13
Waterluvian wrote: post #4

Earlier quoted context omitted.

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

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 quite a bit to convince myself they were right.

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

#27

Post by dekhn »

VWWHFSfQ wrote: post #18
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

to me, well-intentioned systems wiht a high true positive rate and low false positive rate are welcome so long as they follow reasonable etiquette and norms, which this group seems to do.

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

#28

Post by HL33tibCe7 »

mschuster91 wrote: post #20
HL33tibCe7 wrote: post #11

Earlier quoted context omitted.

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.

We’re not talking about deprecating a feature here, we’re talking about the addition of behaviour that will break existing code, potentially in non-trivial and hard to debug ways, and in ways that could easily introduce security vulnerabilities.

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

#29

Post by capitalsigma »

mschuster91 wrote: post #20
HL33tibCe7 wrote: post #11

Earlier quoted context omitted.

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.

Just bump the major version number from 3 to 4, right? How long could that migration take?

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

#30

Post by dekhn »

mschuster91 wrote: post #20
HL33tibCe7 wrote: post #11

Earlier quoted context omitted.

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.

Python does not do this. A change like that would require a major version number increment and the community would revolt.

Too bad we can't go back in time to 1996 or so.

Post reply on HN