4 ms·

> The elephant in the room is that the core devs, after Python 2.7, have taken the very bad habit of breaking compat. For such a popular and core tech a Python,

> The elephant in the room is that the core devs, after Python 2.7, have taken the very bad habit of breaking compat. For such a popular and core tech a Python, this is not responsible. It erodes trust. It also raises the cost of producing good software tremendously. You know, the core devs cannot make it right for everyone. For each its-a-breaking-change-complaint there is a similar amount of we-want-shiny-new-things-and-my-teammates-want-to-move-on-to-shiny-new-language-X complaint. So its clear to me that Python in order to stay relevant needs to evolve, add features, break occasionally with new releases. There was once the idea of combining a couple of breaking changes in one release (I would call this the 'once-in-a-decade' breaking change you seem to find acceptable), that was Py2->Py3 and it was a shitshow, in part, because too many changes happened at once. So I am grateful that we now get the occasional breaking change, one change at a time. I think it is the right way if Python aims to be still relevant in 10 years from now.

BiteCode_dev 6y ago
See my answer to your sibling. It's not an "or" proposition. The 2 to 3 transition was hard because we did an abrupt cut. We could have had few transitioning versions that supported both worlds, then disabled the old ways but with a switch to put them back on if needed for a while, and allow for a more peaceful transition.
- uranusjr 6y ago
  It’s very much an “or” situation from a practical standpoint. Maybe not exclusively or, but it’s unrealistic to say one does not significantly affect the other. Python core dev (CPython or otherwise) is already thin on resource for a long time, and you can’t just keep adding things without cleaning up old cruft. Parties most involved in development of the Python language (CPython devs, the Steering Council, etc.) value sustainability most, so it makes sense they decide to drop old stuff when they see no need of it. On the other side, parties that value stability more (e.g. libraries authors) need to actively lobby their goals to the core devs so they can assess the situation correctly and find the right balance between the two. You can’t just sit there and expect people to understand your needs; you have to tell them, which is what pydantic failed to do in this situation.
  - BiteCode_dev 6y ago
    There was an even smaller team in 2.X, and 2.X broke less stuff while still providing new features. So no. It's a matter of product vision here.
    - uranusjr 6y ago
      > 2.X broke less stuff while still providing new features. By putting off all the cleanups to Python 3. I think I like their current approach better.
      - BiteCode_dev 6y ago
        Python 3 was necessary for cleaning. Having default new style classes, super() and so on are goodies, not necessities. It was necessary for the things that are were not easy to do without breaking compat such as unicode, fixing comparison bugs, etc. Now none of the stuff that broke compat in 3 after the initial release were things that were necessities. They were goodies. You don't need make from __future__ import annotations as default. You don't need to make async/await keyword.
        uranusjr 6y ago
        > You don't need make from __future__ import annotations as default. You don't need to make async/await keyword. By the same logic unicode_literal and print_function should have never been the default? Yeah I guess you can make that case, but I’m not in your camp. Sorry, goodbye.
        BiteCode_dev 6y ago
        I literally wrote "It was necessary for the things that are were not easy to do without breaking compat such as unicode"
        aflag 6y ago
        I see the point that unicode_literal being quite important, but what about print_function? How does it make coding more difficult or awkward?
mixmastamyk 6y ago
I don’t agree because it was the Unicode change that made it difficult, every thing else was relatively trivial. No further huge breaks are even being considered. So kind of a moot point anyway.

BiteCode_dev 6y ago

See my answer to your sibling. It's not an "or" proposition. The 2 to 3 transition was hard because we did an abrupt cut. We could have had few transitioning versions that supported both worlds, then disabled the old ways but with a switch to put them back on if needed for a while, and allow for a more peaceful transition.

uranusjr 6y ago
It’s very much an “or” situation from a practical standpoint. Maybe not exclusively or, but it’s unrealistic to say one does not significantly affect the other. Python core dev (CPython or otherwise) is already thin on resource for a long time, and you can’t just keep adding things without cleaning up old cruft. Parties most involved in development of the Python language (CPython devs, the Steering Council, etc.) value sustainability most, so it makes sense they decide to drop old stuff when they see no need of it. On the other side, parties that value stability more (e.g. libraries authors) need to actively lobby their goals to the core devs so they can assess the situation correctly and find the right balance between the two. You can’t just sit there and expect people to understand your needs; you have to tell them, which is what pydantic failed to do in this situation.
- BiteCode_dev 6y ago
  There was an even smaller team in 2.X, and 2.X broke less stuff while still providing new features. So no. It's a matter of product vision here.
  - uranusjr 6y ago
    > 2.X broke less stuff while still providing new features. By putting off all the cleanups to Python 3. I think I like their current approach better.
    - BiteCode_dev 6y ago
      Python 3 was necessary for cleaning. Having default new style classes, super() and so on are goodies, not necessities. It was necessary for the things that are were not easy to do without breaking compat such as unicode, fixing comparison bugs, etc. Now none of the stuff that broke compat in 3 after the initial release were things that were necessities. They were goodies. You don't need make from __future__ import annotations as default. You don't need to make async/await keyword.
      - uranusjr 6y ago
        > You don't need make from __future__ import annotations as default. You don't need to make async/await keyword. By the same logic unicode_literal and print_function should have never been the default? Yeah I guess you can make that case, but I’m not in your camp. Sorry, goodbye.
        BiteCode_dev 6y ago
        I literally wrote "It was necessary for the things that are were not easy to do without breaking compat such as unicode"
        aflag 6y ago
        I see the point that unicode_literal being quite important, but what about print_function? How does it make coding more difficult or awkward?

mixmastamyk 6y ago

I don’t agree because it was the Unicode change that made it difficult, every thing else was relatively trivial. No further huge breaks are even being considered. So kind of a moot point anyway.