Hacker News Reader

Comment by chungy | Hacker News Reader

> 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.

View on HN

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."

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.

I think it will eventually settle down once people have tried all the ideas and the needs of programmers have stabilized. Kind of like how bolt threads were eventually standardized after decades of everyone doing their own thing. First comes the end of progress, then comes stability. We already have that with some computer things like basic Linux commands or HTML.

You can always stop now if you want. Download the versions of everything you need and never change. But you'll miss out on the cool new hotness that you're wanting everyone else to miss out on if they stop changing too.

I would believe you if it wasn't for the fact that most things being invented in software today are new. The industry keeps reinventing things that people did in the 60's without even doing it properly.

Why doesn't any recent programming languages implement a proper condition system for example? It's not like working implementations hasn't been around for decades.

This industry has a severe case of inability to learn from history so I strongly doubt we'll see things settle down in the near future.

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.

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.

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.

So just wait another 10 years and we'll get there for 3.5.

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.

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.

> 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.

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.

Looks like PEP 492 introduced `async` as a contextual keyword in 3.5, and it became a proper keyword in 3.7.

No, it does break backward compatibility, especially when they introduce new keywords, but also with stuff like: https://news.ycombinator.com/item?id=22928672

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&typ...

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!

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).

Yeah I know it's common in C, but that sure as heck doesn't imply it should be done in Python!

The parent is talking about the former.

Reply on news.ycombinator.com