17 ms·

I began using python during the python3.0 betas, and I watched the 2 vs 3 saga from the (unusual?) perspective of a v3 hobbyist with no back-compat requirements

by gwking 5y ago

I began using python during the python3.0 betas, and I watched the 2 vs 3 saga from the (unusual?) perspective of a v3 hobbyist with no back-compat requirements. What struck me as most significant was the opportunistic breakage of things not related to the unicode transition. In the many years it took to win people over to v3, they could have marched over all the breaking changes a year at a time. Given that side-by-side installs of python3.x point versions are very functional, with or without venvs, this would have been much more palatable. Perhaps harder than it sounds though. I attempted a couple of 2to3 translations of open source libraries over the years, with varying degrees of success. Every time I found that most of the changes were easy, but debugging the broken bits was hard due to the sheer volume of source changes. If instead I could have done conversions where there was only a single major semantic change at a time, it would be so much easier to figure out what was going wrong at any given step. Furthermore, I imagine that a single-breaking-change mentality would lead to better documentation on how to transition for each version. For this reason, I have become rather suspicious of yearly release schedules. Swift is even more frustrating: the version changes are really just dictated by Apple's yearly PR calendar. Some big things get rushed out for WWDC before they are ready, and smaller fixes can get held back until the next year. I would much rather that the language teams just prioritize one thing at a time, release it when it is ready, and foster a community where staying up-to-date on the latest version is easy and desirable (a more complicated story for Apple than for Python I think, due to ABI, OS version, etc). From past discussions on HN I've gathered that there is such a thing as release fatigue, where developers get irritated when libraries release breaking changes too often. Nevertheless I often wonder if languages and libraries could improve faster by making more breaking changes, one at a time, with robust side-by-side installs to facilitate testing across versions. I wish side-by-side library versions were possible in Python, just to facilitate regression testing. Bringing this all back to the post, I sincerely hope that if Python 4 is a breaking change to the GIL, that it will be only that. I'm curious what others think about all this. Thoughts?

kevin_thibedeau 5y ago
> If instead I could have done conversions where there was only a single major semantic change at a time, That was the point of the "from __future__" imports. You could get most of the way toward Python 3 so that 2to3 would be easier to work with and the new semantics could be gradually baked into the code prior to migration. Python 3 had 25 years of cruft to clean up. They won't have to do that again.
fractalb 5y ago
If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. People will just be scared of new releases. No one will adopt a new language version as soon as it releases. Java never breaks backwards compatibility and still there are people running Java 8. Imagine what would happen if every point release carries breaking changes. It makes you feel that the language is not mature, the library ecosystem broken, since you'll have to keep track of version compatibility for each library that you use. It's a nightmare for both library developers and end-users. Few people would like to use such a language
- nuerow 5y ago
  > If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. This. It makes absolutely no sense to claim that having to deal with a single non-backwards compatible release is somehow worse than having to deal with a sequence of non-backwards compatible releases. Even though the migration from Python2 to Python3 faced some resistence, if anything the decision was totally vindicated.
  - burnished 5y ago
    I thought the use case mentioned made sense, that of essentially being able to perform patches in a series, as opposed to trying to fix many breaking changes at once. You know. Iterative development. I think 'makes absolutely no sense' is a little harsh.
- ikerdanzel 5y ago
  Python makes it to #1 over Java now. Python is breaking changes frequently. A lot of libraries need to be "tweak" to get it working even incremental changes within 3.x let along the big rift from 2 to 3. Although logically, few would like such language that breaks, current market for Python adoption buck this trend.
xvland 5y ago
Idealists and free developers (who have created the majority of the Python interpreter) agree with you. Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot. Corporations might even take over more C extensions whose developers are no longer willing to put up with the churn and who have moved to C++ or Java. In the long run, this is bad for Python. But many developers want to milk the snake until their retirement and don't care what happens afterwards.
- simonw 5y ago
  "Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot." In my 20+ year career I have never worked with a programmer that matches this description. Maybe I've got lucky.
isoprophlex 5y ago
O boy, angry rant incoming. I'll say something petulant and overly dramatic, but I don't like the direction in which python is going, and I'm glad there's finally some news about focus on actual innovation instead of tacking on syntactic cruft. I want the python that Guido promised me, with 2021 performance. I don't want some abhorrent committee-designed piece of middle-of-the-road shitware glue language that I must use because everyone uses it. I want a language that doesn't spin it's single-threaded wheel in a sea of CPU cores, and I want a language that has one obvious way of doing things without needing to grok and parse dumb """clever""" hacks that will only be abused by midlevel programmers to show off hoe they saved typing a few lines of additional code. To me, speed + simplicity = ergonomy = joy. I want a new python 4 to focus exclusively and intensely on performance improvements and ergonomy.
- DangitBobby 5y ago
  What recent changes to the language do you specifically dislike?
  - dataflow 5y ago
    Not the parent but := assignment expressions and match expressions are abominations.
    - asah 5y ago
      Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. They're not niche and "should have" been added years ago. If anything, I'm thrilled with the work of the "committee," whose judgments are better than the result of any individual. Postgres is the same. Gone are the days when you invest in a platform like python, and they make crazy decisions that kill the platform's future (e.g. perl5). Ignore small syntax stuff like := and focus on the big stuff.
      - dataflow 5y ago
        > Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. That says nothing about their quality. It just says you like them. If you gave me unhealthy food I'd probably eat it immediately too. Doesn't mean I think it's good for me. > Ignore small syntax stuff like := and focus on the big stuff. They're not "small" when you immediately start using them in a "large fraction of your code". And a simple syntax that's easy to understand is practically Python's raison d'être. They added constructs with some pretty darn unexpected meanings into what was supposed to be an accessible language, and you want people to ignore them? I would ignore them in a language like C++ (heck, I would ignore syntax complications in C++ to a large degree), but ignoring features that make Python harder to read? To me that's like putting performance-killing features in C++ and asking people to ignore them. It's not that I can't ignore them—it's that that's not the point.

by gwking 5y ago

kevin_thibedeau 5y ago

> If instead I could have done conversions where there was only a single major semantic change at a time, That was the point of the "from __future__" imports. You could get most of the way toward Python 3 so that 2to3 would be easier to work with and the new semantics could be gradually baked into the code prior to migration. Python 3 had 25 years of cruft to clean up. They won't have to do that again.

fractalb 5y ago

If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. People will just be scared of new releases. No one will adopt a new language version as soon as it releases. Java never breaks backwards compatibility and still there are people running Java 8. Imagine what would happen if every point release carries breaking changes. It makes you feel that the language is not mature, the library ecosystem broken, since you'll have to keep track of version compatibility for each library that you use. It's a nightmare for both library developers and end-users. Few people would like to use such a language

nuerow 5y ago
> If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. This. It makes absolutely no sense to claim that having to deal with a single non-backwards compatible release is somehow worse than having to deal with a sequence of non-backwards compatible releases. Even though the migration from Python2 to Python3 faced some resistence, if anything the decision was totally vindicated.
- burnished 5y ago
  I thought the use case mentioned made sense, that of essentially being able to perform patches in a series, as opposed to trying to fix many breaking changes at once. You know. Iterative development. I think 'makes absolutely no sense' is a little harsh.
ikerdanzel 5y ago
Python makes it to #1 over Java now. Python is breaking changes frequently. A lot of libraries need to be "tweak" to get it working even incremental changes within 3.x let along the big rift from 2 to 3. Although logically, few would like such language that breaks, current market for Python adoption buck this trend.

xvland 5y ago

Idealists and free developers (who have created the majority of the Python interpreter) agree with you. Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot. Corporations might even take over more C extensions whose developers are no longer willing to put up with the churn and who have moved to C++ or Java. In the long run, this is bad for Python. But many developers want to milk the snake until their retirement and don't care what happens afterwards.

simonw 5y ago
"Corporate developers, who have taken over Python and other people's work, like unnecessary changes, because they get many billable hours of seemingly complex work that can be done on autopilot." In my 20+ year career I have never worked with a programmer that matches this description. Maybe I've got lucky.

isoprophlex 5y ago

O boy, angry rant incoming. I'll say something petulant and overly dramatic, but I don't like the direction in which python is going, and I'm glad there's finally some news about focus on actual innovation instead of tacking on syntactic cruft. I want the python that Guido promised me, with 2021 performance. I don't want some abhorrent committee-designed piece of middle-of-the-road shitware glue language that I must use because everyone uses it. I want a language that doesn't spin it's single-threaded wheel in a sea of CPU cores, and I want a language that has one obvious way of doing things without needing to grok and parse dumb """clever""" hacks that will only be abused by midlevel programmers to show off hoe they saved typing a few lines of additional code. To me, speed + simplicity = ergonomy = joy. I want a new python 4 to focus exclusively and intensely on performance improvements and ergonomy.

DangitBobby 5y ago
What recent changes to the language do you specifically dislike?
- dataflow 5y ago
  Not the parent but := assignment expressions and match expressions are abominations.
  - asah 5y ago
    Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. They're not niche and "should have" been added years ago. If anything, I'm thrilled with the work of the "committee," whose judgments are better than the result of any individual. Postgres is the same. Gone are the days when you invest in a platform like python, and they make crazy decisions that kill the platform's future (e.g. perl5). Ignore small syntax stuff like := and focus on the big stuff.
    - dataflow 5y ago
      > Disagree: the recent changes are things I put to work immediately and in a large fraction of the code. That says nothing about their quality. It just says you like them. If you gave me unhealthy food I'd probably eat it immediately too. Doesn't mean I think it's good for me. > Ignore small syntax stuff like := and focus on the big stuff. They're not "small" when you immediately start using them in a "large fraction of your code". And a simple syntax that's easy to understand is practically Python's raison d'être. They added constructs with some pretty darn unexpected meanings into what was supposed to be an accessible language, and you want people to ignore them? I would ignore them in a language like C++ (heck, I would ignore syntax complications in C++ to a large degree), but ignoring features that make Python harder to read? To me that's like putting performance-killing features in C++ and asking people to ignore them. It's not that I can't ignore them—it's that that's not the point.