If anything, the user experience has been diminished in the move to Python 3, as the maintainer mentions some 3rd party plugins won't work as they need to be ported over.
This would mean considerable dev time to track bugs in the language and dependencies that have been fixed by others in their Python 3 variants. And that means a dev that could have worked on new features now works to do (silly) maintenance work. This clearly does have an impact in the long run.
I am working with Python myself. Everything I moves to Python 3 was a one-time effort, while the stuff where I had stayed with Python 2 means constant effort of making sure it is still safe and no major bug has been discovered in the deps.
I understand the annoyance people have with this, but there aren't to much rational arguments why to use Python 2 over Python 3. In fact it would be the other way around. Before it was minor differences, but the language evolved in a good way since ca. version 3.5 and some of the solutions are really useful (typing, dealing with encodings and unicode, not having to make sure you are using floats when dividing two numbers etc.)
In practise by far the biggest difference is that print foo becomes print(foo), and that is not a big deal if you ask me
The new names are without a doubt better. In a vacuum. But coming from Python 2 to Python 3 and dealing heavily with encodings because I use Python for massaging machine-generated reports, the fact that they reused the same datatype identifier for bytes in P2 as for unicode in P3 really put me off.
Now that I've made the change (OK, six years ago) I'm much happier with the way Python 3 handles bytes and unicode strings. I think it is a model that all languages could learn from. But it should have been called <string> or stayed <unicode> instead!
So it’s kind of harsh to judge that statement in that light isn’t it?
Everyone at that time knew that Python2 is dead and that everything is in transition to python3. Most new code was written for python3 and not even compatible for python2 anymore. So it really was just one guy deciding to maintain his own fort on his own.
Plus as port itself doesn't affect any user experience, it was not emergency situation. It is just that 'we are working FREELY with our own pace, so it will take time. Actual contribution is really appriciated than complains'
There is another similar program I miss is, leafpad. It is dropped by distros as not yet ported.
This balance — however — can change with time. E.g. if one of your major dependency moves to Python 3? Or gets abandoned.
I didn't say it was easy, my point was that over time more and more dependencies make a shift to Python 3 as well, which means at some point Python 2 stuff becomes harder to maintain. Whether that point happens early or late depends entirely on the project.
Additionally I nowhere said that this must be done by anyone — you are projecting here.
> there are a bunch of emotional people
> or some nonsense like that
> Easy for especially weakly socialized young people that many programmers are
It's amusing to watch you call others "weakly socialized" when reading the rest of your comment. Social awareness is not exactly exuding from it, what with the judgments and the confident assertions.
I don't think any good alternatives exist, but if they did, I'd probably switch in a heartbeat. The lead developer for Calibre is extremely annoying. RMS is easier to deal with.
As would I. On a higher order of infinity, I'd use the work of a competent saint over a competent asshole.
Let's not make false dichotomies.
If as a dev one ~not know~, assumes that their code base will have issues because its python 2, then the dev has some issues.
As a case study in open source development, I find it fascinating. In large closed source products, these discussions and their relative dissent is held behind closed doors. I wouldn't be surprised if large parts of YouTube remain Python 2 for a long period of time. But the product owners are aware of these tradeoffs and wouldn't allow public discussion on the subject.
Calibre, from what I've heard has had a historically "bad" codebase. I know nothing about it. But is it the truth?
It feels like a vehicle that has been organically modified over the years by a person who only has a welding machine and a cutting torch and a changing taste in what looks good. But hey: it drives.
Of course you have to know the intricate of the machine to make it behave, but isn't that part of it's charms?
I have noted this quote and intend to apply it to every large software stack I work on from now on because damn if it isn't true of all of them.
Not liking how something works doesn't make it wrong or broken.
So what is this "bad codebase" you seem to feel?