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.

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.

I got on python-dev recently and tried to make the case that breaking changes should be delayed to a X.0 release. It didn’t get very far, they seemed to determined to keep the current low predictability system.

The response was they don’t have enough manpower. The though ignoring deprecated stuff a few releases doesn’t sound particularly hard. I suspect Guido just likes it that way.

Btw, almost no one supports forward compatibility.

If you parse Python 3.8.2 as Python3 8.2.0 then the versioning follows semver nicely.

Then you end up with Python 2 vs Python 3

They've had small breaking changes on many minor releases.

The difference is the scope of the breakage. Python 3.0 broke every project. Python 4.0 certainly wouldn't, they are very timid now. In comparison, these breaks are tiny in scope.

Yeah, I think webdevs and univ students are overly vocal on the internet. They can usually enjoy the new tech, because that's how the industry makes $$$. But there are other parts of the world that don't move that fast. All those "migrate to Python 3" should changed to "develop new projects in Python 3" instead.

I was surprised at the number of libraries that exist to port 3.7/3.8 stuff back to 3.5

Probably because of Debian 9. Now new Debian 10 means there'll be staying at 3.7 for a long time.

Also, if you write library code, you can, and should probably have CI running against Python 3.0, this way at least your code doesn't break when used against a newer version.

> But python3 adds new features in 3.5, 3.6, 3.7 and then immediately breaks all new code on older systems.

It really helps if you think of the versioning as 5.0.x, 6.0.x of Python3, then semver can be applied and you set your shebangs accordingly.

What is the shebang that one should use to run code that targets python3.8 on a system that only has python3.7 installed?

If you use python3 it might randomly fail, if you use python3.8 will fail with 'No such file or directory'

Yep, the latter, I'd much rather a deterministic failure. Or if you're using something like Poetry to package your code, you can specify supported versions and then users of your code will be informed if they lack that Python.

But then if you're trying to write portable Python 3 code without any need for the end user to be pyenv-ing stuff, you probably don't want to be writing 3.8 - off the top of my head, Ansible, for example, targets Python 3.5 for this reason.

I'm not defending this btw, modern Python development is painful, and I taught myself to code in Python, so it hurts to see my first love so.

I guess it would be nice if Python came up with something like Java's source/target which errors if you're using incompatible features.