So fast lint, type checking, code scans, PR assistants, yes, we can swap these whenever. But install flow & package repo, no.
That is unfortunate given the state of pip and conda... But here we are.
So fast lint, type checking, code scans, PR assistants, yes, we can swap these whenever. But install flow & package repo, no.
That is unfortunate given the state of pip and conda... But here we are.
This is how I came to believe this is the case:
Few years ago I wanted to write Python bindings to kubectl. I discovered that in order for that to work cross-platform, I need to make CGo use the same compiler on all platforms as does Python. Unfortunately, on MS Windows, CGO uses MINGW while Python uses MSVC. I wrote to Python dev. mailing list (which still existed at that time) and asked why did they choose to use a proprietary compiler for their "open-source" project. The answer I received in a round-about way was that MSVC was a historical choice, which cannot be presently changed because MS provides Python Foundation with free infrastructure to run CI and builds, and it also provides developers to work on Python (i.e. MS employees get paid by MS to work on Python interpreter). And that they are under orders not to drop MS tools from the toolchain.
Year after year the situation was getting worse. Like in a lot of similar projects, success created a lot of ground for mediocre nobodies to reach positions of power. Python foundation and satellite projects like PyPA started to be populated by people whose way into these positions was not through contributing any useful code, but rather writing pages of code of conduct. This code of conduct and never-ending skirmishes around controlling positions eventually led to some old-timers leaving or being outright kicked out (latest such event was the ban of Tim, the guy who, beside other things, wrote Tim sort, which is a somewhat famous feature of Python).
Year after year MS was pushing its usual agenda they do in every project they get their hands on: add crapload of useless features for the sake of advertising. Make the project swing every way possible, but mostly follow the fashion trends as hard as possible. This is how Python is now devoted to adding as much of ML-style types as possible (in the language with a completely different type system...), AoT compilation and JIT (in the language that's half of the time used to dynamically glue native libraries...) and so on. Essentially, making it a C#, but without curly braces.
MS is smart enough to understand that publicly announcing their ownership of Python will scare a lot of people away from the technology, so they don't advertise it much. But they keep working on ensuring developers' dependency on their tooling, and eventually they will come to collect on their investment.
They’re all so caught up in their internal systems and politics[1] that they don’t seem to know why they’re actually there anymore.
So if someone’s gonna go do an actually-good job and capture the market in the way that Astral is, then that’s exactly what we as a community deserve.
[1]: I mean internal politics. This is a weird alt right “DEI HIRE!” rant.
I'm for small teams doing big pushes, and the example shows such efforts can coexist with healthier long-term governance strategies. It's sad that the effort was needed, but nonetheless, a clear demonstration of separation of concerns working for small engineering team => bigger governance org.
It's also a bad look for the engineering priorities of anaconda inc on their flagship product. I wonder 'how we got there': Anaconda devs help build GPU python stacks, numba, etc, so they are quite good on what they do work on. Is every for-profit packaging-oriented company ultimately not paid enough to keep the packaging core fast? So VC $ just speeds up the schedule to mediocrity?