Szorc: Mercurial's Journey to and Reflections on Python 3

That's dramatic and silly. Red Hat doesn't care about the m68k, and presumably it's not going to hold back important improvements from them. Nor Suse. If Debian cares about the m68k, more than 0.001% of their users care about it in theory, even if they don't use it, and Ubuntu and other Debian derivatives can work around that if they care about it.

It's a free/Free market. Program developers can write what they want, and distributions can use what they want. If a distribution's priorities aren't in line with yours, you can go somewhere else. If they don't want to include your program without some features, you can include those features or not, and if not, they can patch in those features or go without. Don't gripe about those distributions; just add the features or not.

> While you're wielding "proprietary" as a slur, / Can you elucidate the actual argument here?

Ah, see, I was a developer for Debian GNU/Linux. So the idea that we should be working on Free Software as a team is important to me.

> keep in mind that almost every architecture that you think it's important to support is also proprietary.

At different levels, maybe. But a patent only runs 20 years, so any old enough CPU can be reimplemented without license. And the uses aren't proprietary; it's a bunch of hobbyists who benefit, not one big company. There's a difference between an x86-64 chip that's mass-marketed and used in a vast array of devices, and a chip that's only used on Qualcomm's SoCs, and primarily running Qualcomm's code. If LLVM is worried about the cost of bringing an architecture in house, then why let Qualcomm take your developer's time?

> The Linux community expects maintainers to evaluate patches on their merits, not taking into account that sort of quid pro quo.

So you get to judge whether a feature is important or not, but a Linux maintainer can't? You can choose what features you work on, but a Linux maintainer can't? A Linux maintainer can certainly say "your patch causes the kernel to crash; here's the traceback", and leave it at that, even if it will take fifteen minutes of their time or a dozen hours of yours to find the bug. I don't know if they can say that LLVM support isn't worth it--it's probably down to Linus himself--but they can at the very least quit if they feel they have to deal with pointless LLVM patches instead of important patches.

> I'm not sure what arguments you're making here.

I said the m68k is an extreme case. But it is a bellwether; a system that is quick to drop old hardware is much more likely to drop my old hardware, and a system that support the m68k is much less likely to go through and dump support for old hardware. It is something of a matter of pride that Linux works on old systems. Even passing the tests on many of these old systems puts a limit on how slow the software can be.

> once in a while we increase the minimum kernel requirements for rr

Which isn't much a problem because the kernel cares about backward compatibility and doesn't go around knocking off old hardware. It would be a lot more frustrating if every time you had to upgrade rr, you had to upgrade the kernel and seriously worry about the system not coming back up or important parts not working; perhaps many people would stop doing both.

Basically it comes down this paragraph again: It's a free/Free market. Program developers can write what they want, and distributions can use what they want. If a distribution's priorities aren't in line with yours, you can go somewhere else. If they don't want to include your program without some features, you can include those features or not, and if not, they can patch in those features or go without. Don't gripe about those distributions; just add the features or not.

Interesting, how does software on these systems typically know how to decode, display, exchange and generally deal with these encodings?

I understand Python itself enforces explicit encodings, not UTF-8.

If you come across a better paradigm sometime in the future, then bake it into a new version of the language and/or its libraries, and add interoperability features. Python3 is doing this, incidentally: asyncio is a heap of unstructured callbacks that evolved from somebody noticing that you can use "yield from" to build a coroutine runner, then Trio came along with a much better concept that actually enforces structure. Today the "anyio" module affords the same structured concept on top of asyncio, and in some probably-somewhat-distant future asyncio will support all that natively.

Languages, and their standard libraries, evolve.

With Go, this transition to Structured Concurrency is not going to happen any time soon because contexts and structure are nice-to-have features which are entirely optional and not supported by most libraries, thus it's much easier to simply ignore all that fancy structured stuff (another boilerplate argument you need to pass to every goroutine and another clause to add to every "select" because, surprise, there's no built-in cancellation? get real) and plod along as usual. The people in charge of Go do not want to change that. Their choice, just as it's my choice not to touch Go.

You're free to stick with purely dysfunctional programming then. Have fun!

As I said above, it's a necessity due to the design of library APIs. Examples of needed, otherwise unnecessary, encode/decode are plenty (and error-prone). Article mentions a few, I've already mentioned ctypes where for instance structure field names (often read from binary APIs such as c strings, etc) is required to be attributes.

This thread has become a bit off topic. The interesting question for me is Python 2to3 language regressions or which migrations that are feasible, that stage was done in ~ 2010 to 2013 with several Python3 failed migration attempts. Nothing of value has changed since. Half of my Python2 use-cases is not suited for Python3 due to it's design choices and I do not intend to squeeze any problem in a tool not suited for it. That's more of a fact.

The question back of my head for me is about the other half of my use-cases that fits Python3. Given the experience of python leadership attitudes, decisions, migration pains, etc which the article is one example of. Is python3 a sound language choice for new projects?