9 ms·

> I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. I think you are missing the key point here: I don't write a ton of Pytho

> I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.

jasonmp85 4y ago
The point is just you don’t understand how your tools work.
- mikewarot 4y ago
  It seems the actual problem is a disagreement on how tools SHOULD work. A saw still works after a decade on a shelf, programs should still work too because they are tools.
  - jasonmp85 4y ago
    What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.
    - mikewarot 4y ago
      The 100 year old saw I inherited and used to cut down a broken tree last year.
      - vonseel 4y ago
        That's cool, but if the 100 year old saw had been used regularly it would have required maintenance and sharpening to continue working well. Software also requires maintenance. I can't think of any 100-year old software that is being used today (ha-ha). I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working correctly. The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages. End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects. One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version. This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
        mikewarot 4y ago
        >This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple. Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable? When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea of users having to build things in Linux is the problem? It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.
_eht 4y ago
This is such an odd and entitled take for a person who is really trying hard not to care about python.
- deleted 4y ago
  [deleted]
- CamperBob2 4y ago
  It’s like my grandma complaining about the internet being slow... because her CPAP machine is tethered to the clinic with an IP connection and is shutting down every night at 2 AM because a Python script on the server at the other end is no longer running.
  - _eht 4y ago
    I edited my comment before you hit post, but I’ll still reply to LOL at that. Think about what you just said for a sec. Then blame that on a python2.
    - CamperBob2 4y ago
      Laughing at your users is a sure path to unlimited success and good fortune as a developer, for sure.
      - _eht 4y ago
        [flagged]
        dang 4y ago
        We've banned this account for repeatedly and egregiously breaking the site guidelines. Not cool. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

jasonmp85 4y ago

The point is just you don’t understand how your tools work.

mikewarot 4y ago
It seems the actual problem is a disagreement on how tools SHOULD work. A saw still works after a decade on a shelf, programs should still work too because they are tools.
- jasonmp85 4y ago
  What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.
  - mikewarot 4y ago
    The 100 year old saw I inherited and used to cut down a broken tree last year.
    - vonseel 4y ago
      That's cool, but if the 100 year old saw had been used regularly it would have required maintenance and sharpening to continue working well. Software also requires maintenance. I can't think of any 100-year old software that is being used today (ha-ha). I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working correctly. The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages. End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects. One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version. This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
      - mikewarot 4y ago
        >This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple. Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable? When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea of users having to build things in Linux is the problem? It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.

_eht 4y ago

This is such an odd and entitled take for a person who is really trying hard not to care about python.

deleted 4y ago
[deleted]
CamperBob2 4y ago
It’s like my grandma complaining about the internet being slow... because her CPAP machine is tethered to the clinic with an IP connection and is shutting down every night at 2 AM because a Python script on the server at the other end is no longer running.
- _eht 4y ago
  I edited my comment before you hit post, but I’ll still reply to LOL at that. Think about what you just said for a sec. Then blame that on a python2.
  - CamperBob2 4y ago
    Laughing at your users is a sure path to unlimited success and good fortune as a developer, for sure.
    - _eht 4y ago
      [flagged]
      - dang 4y ago
        We've banned this account for repeatedly and egregiously breaking the site guidelines. Not cool. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.