3 ms·

It is hard to keep track of the (no joke) dozens of different weird failures each unique instance of this caused. But I do vaguely recall that sometimes, yes, y

It is hard to keep track of the (no joke) dozens of different weird failures each unique instance of this caused. But I do vaguely recall that sometimes, yes, you now have to go and point each individual utility at the right Python, or set an environment variable, or something. Other times you are relying on some combined build package, which if you want the one that has Python 3, no longer includes Python 2. So then you have to go manually install it. But it's no longer provided as an independent install by that package manager anymore, it was just a coincidence that it was still being included in buildpacks-whatever, so now you have to decide whether you want to figure out how to find and install Python 2 yourself or maybe just go and update everything else to Python 3 too or... UGH. Then you remember "Wait a minute, why I am I doing this, I'm not even a Python programmer!" The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too, so all of a sudden updating something to the Python 3 version means that all of its associated config files have changed format, and now you're updating config files that have worked great for ages and running into bugs there.

happymellon 4y ago
> The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too Your issue with Python is that some people having bad development practices?
- tolmasky 4y ago
  That was one issue I mentioned. You know that. You read my comments. However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear transition path, etc. I think another lesson to take from this experience is the realization that if you create some big "line in the sand" update, you may absolutely inadvertently encourage bad development practices. If the Python 2-to-3 transition had held "ease of transition" as a core value, then it is more likely that that value would have been modeled downstream. By instead initially declaring that the 2-to-3 transition was going to be some watershed moment and people were going to have to update everything, it is not surprising that it could encourage people to just pull the trigger on a bunch of breaking stuff they wanted to do, and come to the (incorrect, but understandable) conclusion that they didn't themselves need backwards compatibility since the entire ecosystem was going through a "unique" non-backwards-compatible change anyways.
  - dagmx 4y ago
    I think part of the issue is that your comments are very ambiguous as to what issues you actually hit. Most of the major Python packages did maintain 2 and 3 compatibility at the same time. Maybe a few packages had bad coding practices but you’re going to hit that in any language. I think you’re extrapolating unfairly
    - comfypotato 4y ago
      Seconded. Noted comment is only mildly snarky at worst. Thanks for your insight on the python3 migrations though. I’ll be wary if I ever see something in that context on the horizon.
    - tolmasky 4y ago
      > I think you’re extrapolating unfairly But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users, such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation they set themselves up for. No other language expects end-users of the programs written in that language to be sympathetic to some internal engineering transition. All this stuff may have great reasons, but you've already failed if you have to explain those reasons to non-Python users, or tell them this is confirmation bias or whatever. It's just not happening with other languages. And this is for big stuff too. Ansible, which uses 2 pythons, one locally and one remotely, was a pain. Add on to this that this was a fairly public boondoggle, that the makers agree wasn't handled well, so whether "fair" or not, this is a common take away I think.
      - dagmx 4y ago
        Tons of other languages have version requirements as part of their end user experience. Whether that’s libc requirements for compiled languages, or Perl language versions being breaking, or even as subtle as differences in behaviour between different compilers such that your system may give different results than another user. So I disagree with your assertion here. Yes it’s unfortunate that this is lifted up to the user, especially because of the fact it’s interpreted, but it’s not anywhere near unique to Python. Therefore I think it’s not a logical outcome to outright avoid Python.

happymellon 4y ago

> The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too Your issue with Python is that some people having bad development practices?

tolmasky 4y ago
That was one issue I mentioned. You know that. You read my comments. However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear transition path, etc. I think another lesson to take from this experience is the realization that if you create some big "line in the sand" update, you may absolutely inadvertently encourage bad development practices. If the Python 2-to-3 transition had held "ease of transition" as a core value, then it is more likely that that value would have been modeled downstream. By instead initially declaring that the 2-to-3 transition was going to be some watershed moment and people were going to have to update everything, it is not surprising that it could encourage people to just pull the trigger on a bunch of breaking stuff they wanted to do, and come to the (incorrect, but understandable) conclusion that they didn't themselves need backwards compatibility since the entire ecosystem was going through a "unique" non-backwards-compatible change anyways.
- dagmx 4y ago
  I think part of the issue is that your comments are very ambiguous as to what issues you actually hit. Most of the major Python packages did maintain 2 and 3 compatibility at the same time. Maybe a few packages had bad coding practices but you’re going to hit that in any language. I think you’re extrapolating unfairly
  - comfypotato 4y ago
    Seconded. Noted comment is only mildly snarky at worst. Thanks for your insight on the python3 migrations though. I’ll be wary if I ever see something in that context on the horizon.
  - tolmasky 4y ago
    > I think you’re extrapolating unfairly But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users, such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation they set themselves up for. No other language expects end-users of the programs written in that language to be sympathetic to some internal engineering transition. All this stuff may have great reasons, but you've already failed if you have to explain those reasons to non-Python users, or tell them this is confirmation bias or whatever. It's just not happening with other languages. And this is for big stuff too. Ansible, which uses 2 pythons, one locally and one remotely, was a pain. Add on to this that this was a fairly public boondoggle, that the makers agree wasn't handled well, so whether "fair" or not, this is a common take away I think.
    - dagmx 4y ago
      Tons of other languages have version requirements as part of their end user experience. Whether that’s libc requirements for compiled languages, or Perl language versions being breaking, or even as subtle as differences in behaviour between different compilers such that your system may give different results than another user. So I disagree with your assertion here. Yes it’s unfortunate that this is lifted up to the user, especially because of the fact it’s interpreted, but it’s not anywhere near unique to Python. Therefore I think it’s not a logical outcome to outright avoid Python.