81–90 of 154 posts
> > 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…
Earlier quoted context omitted.
It's not clear to me that folks would want this behavior globally - I personally would not, because sometimes I want to be able to include curly braces in my strings without it being interpolated, and I prefer the current syntax of having that just work. I'm very comfortable with having to add the 'f' to the string syntax to declare that this particular string should be interpolated. There are other issues you'd have…
Well, you could put a N" your string with{} in it" to type-specify that you are not F-string. In fact, WHY are strings not fully specified every time? There is nothing wrong with F"This is also an f-string". After all, strings are just number sequences with special meanings assigned to some values in some circumstances. Seems to me the problem is similar to wanting 1 be interpreted as an int --- if you want float, yo…
It is: normal strings are the common case.
> > 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 wonder if an autoformatter like black is at play here.
This was posted on Reddit earlier this week with similar negative responses: https://www.reddit.com/r/Python/comments/ubkvrd/10_of_the_66...
This was posted on Reddit earlier this week with similar negative responses: https://www.reddit.com/r/Python/comments/ubkvrd/10_of_the_66...
FWIW, HN is much more positive (while also raising valid points that will be taken into account going forward)
Earlier quoted context omitted.
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 s…
I think that the claim is not that this leaks data in an absolute sense, but rather that changing the behaviour after people have come to rely on it will leak data from currently well behaving applications.
Earlier quoted context omitted.
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 t…