Python 2 will be replaced with Python 3 in the next RHEL major release

In my opinion, Python's primary business value has been that sweet spot it occupies. It's not the most fun, but it's pleasant. It's not the fastest, but it's not too slow. It's not great on resources, but it's not too bad either.

Good people will work with it, and they tend to be the "let's not get creative, let's just get it done" folks that businesses love. Mediocre people do great with it, because it feels much nicer than many of the other things they've worked with and it channels them towards producing better code and being more productive.

Python makes it huge pain-in-the-ass to get weird/creative, and generally frowns upon it, so people tend not to as much. Junior and low-skill contributors can't really get in too much trouble as long as they stick to the program. It's an awesome "just sit the fuck down and do your work" language.

As a language, it's carved out a great space being pleasant, consistent, well-rounded, predictable, etc.. I know there are people on here using it to build their rocket ships. And it can go there too... maybe not as flexible or fun as more extreme alternatives, but it's also less likely to blow up in your face. For those software rocketeers (probably most any SV start-up), updating makes undeniable sense. Python 3 is hands-down better, and they can handle the transition no problem.

But a lot of people don't use Python to build rocket ships. They don't build rocket ships at all. They build delivery trucks and conveyor belts and coffee dispensers. And, for them, the very things that make Python a great choice - a very clean and conservative focus on simplicity and stability - are the very reasons not to switch. There's just not really anything that's been introduced in the last 10 years that is going to make any real difference for their use cases. Whatever trouble they've had with unicode and the other bs has long been lived with. Whatever's missing they've long lived without. And things have been just fine.

Python's killer feature - being a really nice and well-rounded option that works pretty damn good for a large swath of people - is sorta it's undoing here. It's hard to really be that too much more so.

I mean I switched to 3. It's clearly better. But if I was running a Python team that had been effectively just trying to get the job done in 2.7 for over a decade I would have to admit that I wanted to switch for my own sake - I think it would be unlikely to make them that much more happy or productive.

Hell, many people can't even set their same environment back up in a week after loosing their laptop.

How do I mock a temperamental motor controller responding to AT commands? I mean, I'm sure it's hard enough to replicate the oddities of their serial port parser, but the temperamental part is gonna be tricky. This is an embedded system I'm talking to, which is parsing bytes coming over a serial port in an interrupt service routine at 16 MHz with 4 kB of RAM. Not an async callback with JSON in a nodejs app with GHz of processing power and 8 GB of memory. Emphasis on: temperamental.

Oh, and don't forget. This is a mechanical system, not a website. We'll have to put torque and strain gauges on the system to make sure it's doing what we want.

The skinny is, the system my python scripts talk to is far too complicated to just "stub out". You may be able to test 90% of the cases, but what you really worried about is that 10% of freak accidents that break things. Look up the Therac 25 and how that failed.