Hacker News Reader

Comment by leadingthenet | Hacker News Reader

I never understood why they didn't remove the previous ones.

Isn't there supposed to be only one obvious way of doing these things?

I would support removing the weird '%' operator, but str.format definitely still has uses. For one you can't make templates using f-strings since they are immediately evaluated.

Python already broke backwards compatibility once. It didn't got over well

You can't just remove things, that'd break stuff!

That is why scala has scalafix[1] where library maintainers can provide rules along with newer versions of libraries that can be used to automatically, either at build time or out of band on the source, translate old constructs/patterns in the new.

See it as deferred refactoring for library maintainers. Library maintainers that work in a monorepo with their users get this refactoring feature for free.

[1]: https://scalacenter.github.io/scalafix

I have two thoughts on this: One is that tools like scalafix no-doubt rely heavily on static analysis to ensure correctness of their program transformations. I'm not sure a hypothetical "pythonfix" tool will be quite as feasible for untyped code bases.

And also, the issue isn't really with library maintainers when it comes to Python syntax changes. It's with all the user code written in Python. I tried converting my programs from Scala 2.12 from 2.13, and I failed so hard. I couldn't justify the time commitment, even with tools like scalafix to automate stuff. It's just not that smart.

All this is to say, let's not pretend that breaking changes to a programming language are ok. If you have to do break stuff once or twice in the lifetime of your language, fine. But accepting breaking changes as the status-quo is a failure of a language, by definition, IMO.

lib2to3 exists and is used by tools to do this kind of automatic refactoring for python. The idea of having a migration path to the "blessed" way to do things is pretty neat!

As an occasional python developer - I remember you could use `from future import <function>` to use python3 features in python 2.x. perhaps it would be possible to introduce a `past` package to include deprecated language features? of course this would still break compatibility in some cases, but would make it much easier to update them

> perhaps it would be possible to introduce a `past` package to include deprecated language features?

Deprecated language features are, by definition, still present and need no special incantation to miss, though they may produce Deprecation warnings to encourage you to update your code. Removed features would, I guess, be something you could do this for, except that generally the whole benefit of removing features is getting rid of the supporting code and the effort of maintaining it and it's interactions with new code.

This is why the language is getting bloated. People shouldn't be so obstinately against breaking changes.

This is quite an alarming attitude that seems to be most common among the Python community. It seems like the 2->3 transition filtered out devs who felt strongly about backwards compatibility and the remaining devs have relatively little patience for objections against breaking changes.

There is a huge benefit to keeping existing code working as it is. Both for businesses and the ecosystem. It benefits everyone if the language does everything it can to keep that intact.

This is the same orange site that thinks the Python 2 to Python 3 breaking changes are still relevant and worth arguing about in 2021.

Yes, f-strings are now the obvious way to format strings _if_ the template is fixed (not variable at runtime) _and_ variables are defined in the current scope. There are many many cases where this does not apply: hence str.format is still required.

  greeting = "hello {}"
  greet = partial(str.format, greeting)
  greet("world")

How would you pass a variable format string to f"" ?

You can use variables in the formats.

  >>> flt = 1.2345
  >>> two = 2
  >>> f"{flt:.{two}f}"
  '1.23'

That is the opposite of the problem being posed. The question is how you define `greet` using f-strings.

  greet = lambda x: f"hello {x}"

  greet = lambda x: f"hello {x}"

What if "hello {x}" is not a static string but was read from somewhere else?

Surely this would not work:

  greeting = "hello {x}"
  greet = lambda x: f greeting

Something along the lines of...

    code = 'f"{input()} {x}"'

    lambda x: eval(code)

(Please don't do this)

    code = 'f"here it is {eval(input())}"'
    (lambda: eval(code))()

k, there we go

Yes, I'll stick to using str.format :)

That isn't the purpose for f-strings. You still have % and .format

You can’t use f-strings for that.

That was exactly my point.

I mean, if you're comfortable with `functools.partial`, lambdas are no great stretch:

  greet_fstring = partial(lambda _,s: f"hello {s}", greeting)

Why is the example

  greet = partial(str.format, greeting)
  greet("world")

as opposed to just

  greeting.format("world")

?

The real question is why they didn't just write:

    greet = greeting.format

It was implying you could use the str.format function as argument to other computations, something you cannot do with f-strings.

Or read the string to be formatted from a file, to name another use case.

Reply on news.ycombinator.com