5 ms·

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?

elisaado 6y ago
You can't just remove things, that'd break stuff!
- spockz 6y ago
  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 https://scalacenter.github.io/scalafix
  - lopatin 6y ago
    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.
    - properdine 6y ago
      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!
- leadingthenet 6y ago
  This is why the language is getting bloated. People shouldn't be so obstinately against breaking changes.
  - heavyset_go 6y ago
    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.
  - SubjectToChange 6y ago
    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.
- mahathu 6y ago
  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
  - dragonwriter 6y ago
    > 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.
linkdd 6y ago
greeting = "hello {}" greet = partial(str.format, greeting) greet("world") How would you pass a variable format string to f"" ?
- pletnes 6y ago
  Or read the string to be formatted from a file, to name another use case.
- eljost 6y ago
  You can use variables in the formats. >>> flt = 1.2345 >>> two = 2 >>> f"{flt:.{two}f}" '1.23'
  - thaumasiotes 6y ago
    That is the opposite of the problem being posed. The question is how you define `greet` using f-strings.
    - sumzup 6y ago
      greet = lambda x: f"hello {x}"
- thaumasiotes 6y ago
  Why is the example greet = partial(str.format, greeting) greet("world") as opposed to just greeting.format("world") ?
  - contravariant 6y ago
    The real question is why they didn't just write: greet = greeting.format
    - linkdd 6y ago
      It was implying you could use the str.format function as argument to other computations, something you cannot do with f-strings.
notatoad 6y ago
Python already broke backwards compatibility once. It didn't got over well
contravariant 6y ago
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.
perrygeo 6y ago
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.

elisaado 6y ago

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

spockz 6y ago
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 https://scalacenter.github.io/scalafix
- lopatin 6y ago
  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.
  - properdine 6y ago
    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!
leadingthenet 6y ago
This is why the language is getting bloated. People shouldn't be so obstinately against breaking changes.
- heavyset_go 6y ago
  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.
- SubjectToChange 6y ago
  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.
mahathu 6y ago
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
- dragonwriter 6y ago
  > 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.

linkdd 6y ago

greeting = "hello {}" greet = partial(str.format, greeting) greet("world") How would you pass a variable format string to f"" ?

pletnes 6y ago
Or read the string to be formatted from a file, to name another use case.
eljost 6y ago
You can use variables in the formats. >>> flt = 1.2345 >>> two = 2 >>> f"{flt:.{two}f}" '1.23'
- thaumasiotes 6y ago
  That is the opposite of the problem being posed. The question is how you define `greet` using f-strings.
  - sumzup 6y ago
    greet = lambda x: f"hello {x}"
thaumasiotes 6y ago
Why is the example greet = partial(str.format, greeting) greet("world") as opposed to just greeting.format("world") ?
- contravariant 6y ago
  The real question is why they didn't just write: greet = greeting.format
  - linkdd 6y ago
    It was implying you could use the str.format function as argument to other computations, something you cannot do with f-strings.

notatoad 6y ago

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

contravariant 6y ago

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.

perrygeo 6y ago

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.