[discordance]

Why? - I don't understand how Calibre's move from Python 2 to Python 3 should impact you as an end-user. The user experience should be identical.

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.

[atoav]

Python 2 is EOL, which means the language (and worse: probably all non-standard dependencies you are using) are stuck in time unless everybody decides to go with Python 2 and ditch Python 3.

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

[croh]

Please understand how big codebase is. Porting pyqt stuff is not easy. If you see comments in bug, author and others already started to work on port, but they knew it will take time and they were sure of easyness of maintaining old version. It is always easy to whine than UNDERSTANDING and DOING actual work. As you're already developer, you must know that if it is that easy, author had it ported already

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.

[atoav]

I do understand that, my point was precisely that this is always a tradeoff between multiple things. If maintaining the old version is easier than migrating to the new one, you don't do it.

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.

[dotancohen]

For me the biggest issue was the reuse of datatype identifiers for different datatypes. Python 2 had a byte string <str> and a unicode string <unicode> types. Python 3 still has both types, but now the byte string type is called <bytes> and the unicode string type is called <str>.

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!

[atoav]

Yeah, indeed many things about that transition could have been handled better. E.g. it should have been more small incremental steps, the version 2 should have been phased out quicker, there should have been tooling to help transitions like these etc.

[bluGill]

Python2 is old and has been in widespread use for years. Realistically, how likely is it that a new bug will be found that affects Calibre.

[addicted]

As far as I know Python 2 wasn’t EOL at the time of the statement from the author of Calibre.

So it’s kind of harsh to judge that statement in that light isn’t it?

[slightwinder]

Actually, it was. The last version of Python2 was 2010 released, with only bugfix-versions coming after this. And EOL for those bugfix-versions was also set at the time of the statement, and actually even twice, as the date was pushed back by some years.

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.

[Larrikin]

If as a dev you know their code base will have issues based on what you know about the ecosystem why would that not be a reason to hold off on the product. If they prove themselves despite the issues you choose them, if they realize the issues with their response and adapt you choose them, and if the product blows up because of foreseen issues you predicted you didn't waste your time on a product you suspected was doomed and probably found an alternative in the meantime.

[snoshy]

It's a good "smell test" as a developer. It's one of the "secret skills" you earn as someone who knows how to build systems, even though it's anything but secret.

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?

[mdoms]

Calibre is one of those pieces of software where you can "feel" the bad code base as an end user. It's obvious in the way that seemingly simple things are never improved, making changes is obviously hard. It is truly one of the jankiest software systems I have used.

[slightwinder]

As a user I can't "feel" this bad code at all. Sure, it's has It's own philosphy of things and ocaasional bug like every software, but it's still one of the most stable and productive apps I know. there are regular updates, no big deal breakers and faults coming from the project itself. It simply works and grows, despite being so complex and powerful.

So what is this "bad codebase" you seem to feel?

[valvar]

I mean the UX could be better of course, but are there any specific issues that come to mind? I've never felt that way when using Calibre. I always thought of it as a rather smooth piece of software. Unlike some other pieces of libre software, like LibreOffice...

[michaelmrose]

It does a lot of things and it does all of them at least reasonably well. Some parts like reading ebooks has 75 different choices but I don't think anything nor any combination of things does everything it does and any 3 choices to do 75% of what it does would doubtlessly be vastly jankier.

Not liking how something works doesn't make it wrong or broken.

[atoav]

I understand what you mean, but still: it kinda works.

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?

[zimpenfish]

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

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.

[ornornor]

I still don’t get the rationale. It’s not like calibre somehow converts your ebooks to a proprietary format that you can’t use without calibre or that it modifies your ereader so that it won’t work without caliber either.

[BeetleB]

It's an ebook management tool. True, it's not proprietary, but if you rely heavily on it, it's a pain to switch to something else later. When you have very reasonable doubts about the future of the project, it makes sense to look for alternatives.

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.

[ornornor]

I for one don't really deal with Calibre's author personally. I enjoy Calibre very much, and I'm grateful to its author. But you do you, if that precludes you from using Calibre that's fine.

[BeetleB]

I enjoy Calibre a lot as well and do not deal with him personally, and am grateful for what he has produced, but if there were alternatives that served my needs, I'd switch. Gratefulness doesn't mean overlooking one's flaws or loyalty.

[michaelmrose]

Most of the time as a user you deal with the consequences of the developers competence or lack thereof not their personality. I'd infinitely rather use the work of a competent asshole than an incompetent saint. I've filled out bug reports and feature requests for calibre and found that even when I didn't agree with Kovid he was relatively easy to approach and responsive to dialog even when I didn't necessary agree with the response I feel like I've derived a ton of value from his work for zero dollars and zero cents.

[BeetleB]

> I'd infinitely rather use the work of a competent asshole than an incompetent saint.

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.

[codegladiator]

> If as a dev you know their code base will have issues

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.

[newen]

Calibre is 13 years old and widely used. There is no reason someone would want to not use it because of as trivial a reason as Python 2 to 3 except for some rationalized emotional nonsense about the Python 2 to 3 shift. Every time Python 2 vs 3 is discussed, there are a bunch of emotional people spewing vitriol about luddites or some nonsense like that. Easy for especially weakly socialized young people that many programmers are to get caught up in that.

[BeetleB]

> There is no reason

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

[newen]

Seems I touched a nerve there. I see a pattern and say it. Don’t take it so personally.