3 ms·

> python2: just works. If you install python2 you get the same stable version everywhere. > python3: Oh, sorry, you used a feature that was added in 3.x and th

by chungy 7y ago

> python2: just works. If you install python2 you get the same stable version everywhere. > python3: Oh, sorry, you used a feature that was added in 3.x and this system has 3.(x-1) so now you get SyntaxErrors, or worse, random runtime exceptions. Maybe you were used to Python 2.7 only as "Python 2", but when it was in active development, major 2.x releases had the exact same thing. I had some serious troubles when the latest version of RHEL was on 2.4 while the rest of the world had 2.6 with very large changes. There were all kinds gross hacks just to make things work on an older, common version.

mehrdadn 7y ago
Are you talking about making Python 2.6 code work on Python 2.4, or about making Python 2.4 code work on Python 2.6? The parent is talking about the latter for Python 3 (edit: looks like I misunderstood, never mind), but you seem to be talking about the former. They're not the same thing.
- chungy 7y ago
  Python doesn't break backwards compatibility like that. Code written against 3.0 will still work perfectly fine on 3.8; likewise for 2.0 code running against 2.7. Parent seemed to be talking about the reverse: going backwards, and implying that 2 didn't have major new features, even though it very much did.
  - mehrdadn 7y ago
    No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672 https://news.ycombinator.com/item?id=22928672
  - pansa2 7y ago
    > Code written against 3.0 will still work perfectly fine on 3.8 Not 100%. For example, using `async` as a variable name works in 3.0 but not in 3.8, where it is a keyword.
    - chupasaurus 7y ago
      Are you talking about PEP-0492? It was added in 3.5.2 with deprecation of previous behavior in 3.7, release dates of those are separated by exactly 2 years, with deprecation warnings in 3.6.
      - pansa2 7y ago
        Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.
  - justinsaccount 7y ago
    Python3.8 is breaking things left and right because people are using the walrus operator and then realizing that users don't actually have python3.8 installed. https://github.com/search?q=remove+%22walrus+operator%22&type=Commits https://github.com/search?q=remove+%22walrus+operator%22&typ...
    - mehrdadn 7y ago
      Wow this is horrifying: if (diff := coord - lower) < self.view_dist: I would've assumed walrus would've only been used at the top level of the expression, not nested inside a conditional!
      - mianos 7y ago
        A pretty normal C idiom. Maybe some old C programmers wanted it? (One of which I am but I like my python pythonic so it wasn't me).
        mehrdadn 7y ago
        Yeah I know it's common in C, but that sure as heck doesn't imply it should be done in Python!
- usmannk 7y ago
  The parent is talking about the former.
justinsaccount 7y ago
Oh, yeah, I started around 2.3 so you're totally right. But I mean that since python2.7 came out 10 years ago, python2 has been a stable platform for building things.
- staticassertion 7y ago
  So just wait another 10 years and we'll get there for 3.5.
userbinator 7y ago
I think you're making a very similar point to the comment you're replying to --- that "dead" really means stability; no more worrying about changes that make things stop working. Personally, as a developer who has been working on software for a few decades, I've gotten increasingly irritated with the growing churn of platforms today and the astonishing waste of time for everyone who has to deal with it. It's hard to hit a moving target or build on a shaky foundation, but that's what the state of software seems to be today. Instead of platforms approaching stability and spending time on the actual problems at hand, countless developer hours are wasting solving problems created by others "pulling the rug out from under them". I guess the younger generation of developers just hasn't felt enough of that pain yet, or they're overeager to try new things without thinking of the consequences. I've always taken the conservative approach and as a result some of the software I've written has needed little if any new attention in decades. Some utilities I wrote 25 years ago (not in Python, obviously), I still use regularly. "It's not the tool, it's how you use it."
- cle 7y ago
  It’s a combination of the tool and how you use it. And the environments that tools run in today are sometimes dramatically different than they were 25 years ago. As constraints and limitations change due to technological progress, economics, etc., so too does our software. I don’t see anything wrong with that. Nor do I see anything wrong with tools that adopt a tenet of not changing, both have value.
  - falcolas 7y ago
    25 years is one thing. 1 year is another. There has to be a middle ground. 10 years doesn’t seem too bad. And Python 2.7 has shown that to be remarkably reasonable.
- CountSessine 7y ago
  I think you're making a very similar point to the comment you're replying to --- that "dead" really means stability; no more worrying about changes that make things stop working. But you're missing the same point that the parent commenter is missing - stability only came because Python 2 has been sitting at 2.7 for so long. And you're also missing the point that you can have the same stability by sticking to 3.6 or 3.7 or 3.8 or whatever your fancy is. If you stick with 3.7, I assure you that 3.7 will remain exactly the same and no one is going to pull your rug out from under you. Just don't upgrade. But don't ask for new features either.

by chungy 7y ago

mehrdadn 7y ago

Are you talking about making Python 2.6 code work on Python 2.4, or about making Python 2.4 code work on Python 2.6? The parent is talking about the latter for Python 3 (edit: looks like I misunderstood, never mind), but you seem to be talking about the former. They're not the same thing.

chungy 7y ago
Python doesn't break backwards compatibility like that. Code written against 3.0 will still work perfectly fine on 3.8; likewise for 2.0 code running against 2.7. Parent seemed to be talking about the reverse: going backwards, and implying that 2 didn't have major new features, even though it very much did.
- mehrdadn 7y ago
  No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672 https://news.ycombinator.com/item?id=22928672
- pansa2 7y ago
  > Code written against 3.0 will still work perfectly fine on 3.8 Not 100%. For example, using `async` as a variable name works in 3.0 but not in 3.8, where it is a keyword.
  - chupasaurus 7y ago
    Are you talking about PEP-0492? It was added in 3.5.2 with deprecation of previous behavior in 3.7, release dates of those are separated by exactly 2 years, with deprecation warnings in 3.6.
    - pansa2 7y ago
      Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.
- justinsaccount 7y ago
  Python3.8 is breaking things left and right because people are using the walrus operator and then realizing that users don't actually have python3.8 installed. https://github.com/search?q=remove+%22walrus+operator%22&type=Commits https://github.com/search?q=remove+%22walrus+operator%22&typ...
  - mehrdadn 7y ago
    Wow this is horrifying: if (diff := coord - lower) < self.view_dist: I would've assumed walrus would've only been used at the top level of the expression, not nested inside a conditional!
    - mianos 7y ago
      A pretty normal C idiom. Maybe some old C programmers wanted it? (One of which I am but I like my python pythonic so it wasn't me).
      - mehrdadn 7y ago
        Yeah I know it's common in C, but that sure as heck doesn't imply it should be done in Python!
usmannk 7y ago
The parent is talking about the former.

justinsaccount 7y ago

Oh, yeah, I started around 2.3 so you're totally right. But I mean that since python2.7 came out 10 years ago, python2 has been a stable platform for building things.

staticassertion 7y ago
So just wait another 10 years and we'll get there for 3.5.

userbinator 7y ago

I think you're making a very similar point to the comment you're replying to --- that "dead" really means stability; no more worrying about changes that make things stop working. Personally, as a developer who has been working on software for a few decades, I've gotten increasingly irritated with the growing churn of platforms today and the astonishing waste of time for everyone who has to deal with it. It's hard to hit a moving target or build on a shaky foundation, but that's what the state of software seems to be today. Instead of platforms approaching stability and spending time on the actual problems at hand, countless developer hours are wasting solving problems created by others "pulling the rug out from under them". I guess the younger generation of developers just hasn't felt enough of that pain yet, or they're overeager to try new things without thinking of the consequences. I've always taken the conservative approach and as a result some of the software I've written has needed little if any new attention in decades. Some utilities I wrote 25 years ago (not in Python, obviously), I still use regularly. "It's not the tool, it's how you use it."

cle 7y ago
It’s a combination of the tool and how you use it. And the environments that tools run in today are sometimes dramatically different than they were 25 years ago. As constraints and limitations change due to technological progress, economics, etc., so too does our software. I don’t see anything wrong with that. Nor do I see anything wrong with tools that adopt a tenet of not changing, both have value.
- falcolas 7y ago
  25 years is one thing. 1 year is another. There has to be a middle ground. 10 years doesn’t seem too bad. And Python 2.7 has shown that to be remarkably reasonable.
CountSessine 7y ago
I think you're making a very similar point to the comment you're replying to --- that "dead" really means stability; no more worrying about changes that make things stop working. But you're missing the same point that the parent commenter is missing - stability only came because Python 2 has been sitting at 2.7 for so long. And you're also missing the point that you can have the same stability by sticking to 3.6 or 3.7 or 3.8 or whatever your fancy is. If you stick with 3.7, I assure you that 3.7 will remain exactly the same and no one is going to pull your rug out from under you. Just don't upgrade. But don't ask for new features either.