[janoc]

Sorry but that's nonsense. Python 3 has been released in 2008 - 15 years ago. And the last Python 2 version has been EOLed 1.1.2020, three years ago, after a decade of deprecation!

With your argument about compatibility no programming language would ever be able to evolve or deprecate/remove some features. Look at how many things changed e.g. between recent C++, Rust or C# major releases. Python had only one major revision in 15 years in comparison!

If you are using software that still requires Python 2 that's very much a problem of that application and not Python. Complain to the vendor responsible, not about Python. They had ample time to update their code.

End users had no business touching Python 2 for at least a decade now. And upward compatibility between the point releases of Python is (and has been) generally pretty good.

[JohnFen]

> Sorry but that's nonsense.

I'm not lying. This problem cost me a full weekend earlier this year. I may have misremembered the exact version numbers, though. Perhaps it wasn't between 2 and 3. Is there a Python 4?

The problem is that you can't have one Python interpreter that covers all versions of Python, and Python is very unforgiving about using the wrong interpreter version.

In any case, it was a serious problem that cost me a lot of time and really soured me on Python as an end user. I've not encountered a similar issue with any other language before, so this appears to be uniquely a Python thing.

But I don't know. I'm happy enough to just avoid Python-based anything whenever possible now.

[janoc]

There is no Python 4 - and may not ever be.

If you have downloaded Python 2, you must have done it intentionally, it isn't even available from the Python.org website download anymore - and had not been for a long time.

>The problem is that you can't have one Python interpreter that covers all versions of Python, and Python is very unforgiving about using the wrong interpreter version.

Because it doesn't make sense. The language evolves. Nobody is going to stop working on it only because it could break some old code somewhere. The changes from 2 to 3 happened *15 years ago*.

There is no reason to try to compile/run old Python 2 code today - and if you still do need it for some reason, then you need to download the Python 2 version (which are still available, if you need them but one has to look for them). But then you better know what you are doing.

If some old code requires Python 2, any somewhat experienced Python developer will spot that right away (e.g. the use of print statement in Python 2 vs. print() function in Python 3 is a dead giveaway).

>In any case, it was a serious problem that cost me a lot of time and really soured me on Python as an end user. I've not encountered a similar issue with any other language before, so this appears to be uniquely a Python thing.

I don't doubt it has costed you a lot of time but this was a problem entirely of your own doing by not doing your homework.

You would have exactly the same problems if you tried to compile old K&R C code or C++ code from 20 years ago using modern compilers. Or tried to feed modern C# code to a compiler from 10 years ago. Or, God forbid, tried to run some modern Javascript code using old browser - or that old HTML with Flash and what not in a modern browser ...

Python is actually much more lenient in this regard because a major language change has happened only once, 15 years ago, with Python 2 being deprecated for well over a decade. The point releases are all upward compatible with no issues.

[jen20]

I’m with you on Python 2 to 3 being a fine idea and an improvement but…

> You would have exactly the same problems if you tried to compile old K&R C code or C++ code from 20 years ago using modern compilers. Or tried to feed modern C# code to a compiler from 10 years ago.

If you feed 10 year old C# to a modern compiler it will compile it fine. I’d imagine most C and C++ of even 20-year vintage will still compile. The issue is of forward compatibility, not backwards.

[pjmlp]

No it won't, as it might be using the breaking for change introduced in C# 5, or .NET Framework features not made available on .NET Core.

Likewise C and C++ have had enough breaking changes since 2010.

[neonsunset]

It depends. Some projects can be retargeted to netstandard2.0/net6(8).0 without any changes at all, some require minor update of dependencies and some other - do face breaking changes in library code because APIs did get deprecated.

With that said, neither IL nor C# itself had any changes breaking forward compatibility (aside from a very early change to foreach recently discussed here).

[pjmlp]

C# isn't used in isolation without standard library.

Also, "it depends" isn't the same as "If you feed 10 year old C# to a modern compiler it will compile it fine."

[AlbertCory]

all arguably true, but it has no bearing on whether 3 was necessary in the first place.

> With your argument about compatibility no programming language would ever be able to evolve

"evolve" and "change" are not ends in themselves. If it was usable as it was, then there was no need to evolve or change in an incompatible way.

15 years ago: also irrelevant. World War One was unnecessary, and that was 109 years ago. Whatever issues existed are sorted out by now, but that doesn't mean it had to happen.

[janoc]

There have been some very good reasons why Python 3 made those changes.

That you find them unnecessary because the original code was "usable as is" for you is irrelevant.

The reasons why these changes have been done (for a developer they have been fairly minor) has been hashed and rehashed for the past 15 years, Guido van Rossum wrote on it extensively too.

Most has been performance-related (Python 3 is significantly faster than 2) and probably the biggest user-visible change is the clean up of string handling with everything being Unicode now.

Frankly, anyone complaining about this stuff today is just beating the old dead horse for the sake of having something to complain about. The same like some people constantly bringing up the Linux systemd discussions after more than a decade, even though they are completely irrelevant today.

[AlbertCory]

the age of an unnecessary change is irrelevant. Here's your sequence:

1. It's not true

2. It's true, but it's not important

3. It's true, and it's important, but we're tired of talking about it.