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

31–40 of 154 posts

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

#31

Post by swatcoder »

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.

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/OS changes that have no material impact on our own otherwise-mature projects.

It's worth being judicious about where breaking changes are applied, right?

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

#32

Post by polio »

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.

Most developers will require an arsenal of static analysis tools to achieve maximum productivity. Linters are an example of such a tool, but they don't exist as part of the language spec itself, AFAIK.

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

#33

Post by krisoft »

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.

> treat it as a fatal error

Did you think this through? What would you treat as a fatal error? How would the compiler know if a particular string is old style code wanting to print some characters between curly braces or new style code wanting to string interpolate a variable?

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

#35

Post by noobermin »

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?

The assumption I'm thinking they mean is to make formatting default and unformatted not default, for example, how "raw" strings were treated, escaped characters are replaced with the ascii code by default unless the string is raw, signified by an 'r' prefixed in front.

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

#36

Post by noobermin »

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've done this too many times and we've had enough pain, let's please proceed at a pace where we can worry about delivering our product and not updating formatted strings, thank you.

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

#37

Post by _8j50 »

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.

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

#38

Post by asvitkine »

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?

If you only make it work with string literals (e.g. generate the underlying formatting logic at parse time), it wouldn't allow arbitrary inputs to be treated as f strings.
Post reply on HN