NPM is the other major source of issues (congrats for now, `cargo`!), and TIL that NPM is A) a for-profit startup (??) and B) acquired by Microsoft (????). In that light, this gift seems even more important, as it may help ensure that relative funding differences going forward don’t make PyPi an outsized target!
(Also makes me wonder if they still have a Microsoft employee running the PSF… always thought that was odd.)
AFAIU the actual PSF development team is pretty small and focused on CPython (aka language internals), so I’m curious how $750,000/year changes that in the short term…
EDIT: there’s a link below with a ton more info. This gift augments existing gifts from Amazon, Google, Microsoft, and Citi, and they soft-commit to a cause:
Planned projects include creating new tools for automated proactive review of all packages uploaded to PyPI, improving on the current process of reactive-only review. We intend to create a new dataset of known malware that will allow us to design these novel tools, relying on capability analysis.You might be confusing the Python Steering Council - responsible for leadership of Python language development - with the PSF non-profit there.
The PSF is lead by a full-time executive director who has no other affiliation, plus an elected board of unpaid volunteer directors (I'm one of them).
Microsoft employees occasionally get voted into the board, but there is a rule to make sure a single company doesn't have more than 2 representatives on the board at any one time,
The board also elects a chair/president - previously that was Dawn Wages who worked at Microsoft for part of that time (until March 2025 - Dawn was chair up to October), today it's Jannis Leidel from Anaconda.
Meanwhile the Python steering council is entirely separate from the PSF leadership, with their own election mechanism voted on by Python core contributors. They have five members, none of whom currently work for Microsoft (but there have been Microsoft employees in the past.)
Similar story with Mozilla.
[0] https://www.python.org/psf/annual-report/2024/ [1] https://en.wikipedia.org/wiki/Outreach
In 2020 [1] 48.1% went to "Packaging Work Group/Infrastructure/Other" (I assume because in person pycon was canceled).
I also checked 2021 [2], which was 32.7% pycon and 31.2% pip etc...
Also 2022 [3], 57.8% pycon, 26.6% Packaging Work Group...
In 2023 [4], 60.5% pycon, and Packaging Work Group expenses decreased to 9.6% because of fastly now provides the bandwidth/hosting: "We are grateful to Fastly for making the online services that the PSF provides possible, so that we can invest time and resources into advancing our infrastructure to better meet community wants and needs."
So your assertion seems to have never been true.
[0] https://www.python.org/psf/annual-report/2019/
[1] https://www.python.org/psf/annual-report/2020/
[2] https://www.python.org/psf/annual-report/2021/
I feel it is important to look at the facts, not just vibes.
During the 2010s, the packaging group was begging for help. "We're only volunteers," a common refrain: https://news.ycombinator.com/item?id=46605018
During the 2020s, funding for packaging was provided by Mozilla and Chan-Zuck, because PSF wouldn't do enough.
As we all know, astral stepped in and solved the problem for them. I moved to their tools as soon as was possible. And not simply because they were fast, but because they work.
For example, here's one that they broke for my package a couple of years ago in pip, and never fixed: https://github.com/pypa/packaging/issues/774
Those are "fiscal sponsorships" meaning the PSF holds money for other organizations. The PSF is not funding Pallets (or Boston Python or North Bay Python, etc, etc). They accept money earmarked for those organizations and provide administrative support. Details: https://www.python.org/psf/fiscal-sponsorees/
Why is that? Is there lessons to be learned from the Linux Foundation how to actually effectively and responsibly manage that sort of money, in those types of projects?
> CPython core developer Paul Moore described his involvement in the
> packaging community and said: “it’s struggling under the weight of its own
> popularity … the individuals involved are doing their best under what are
> frankly near-impossible conditions.”
> Moore questioned whether the fact that so many businesses now depend on
> Python and PyPI meant that “maybe a purely volunteer basis simply can’t
> work any more,” though he hoped this is not the case.> The PSF would not be fulfilling their mission if they only funded packaging until packaging was "solved" (whatever that might mean) and only then did they fund outreach.
But they did the opposite. So they still didn't fulfill it, astral had to.
But also they rely heavily on Python and want to support the ecosystem.
If you missed it, they bought Bun a while back, which is what Claude Code is built in: https://bun.sh/blog/bun-joins-anthropic
One of her biggest projects was shepherding a large group of very old donations through a legal process to remove provisions in the donation agreements that were now illegal. In these cases the donors were long deceased, and the most common rule that needed to be changed was targeting race or ethnicity (e.g.: funds setup to help black people, or Irish, etc...).
The sheer number of different variations on "donor intent", or even just the wording on that legal document was astounding. There was always a tension between my wife's group and the group that was bringing in the money ("stewardship"), her group wanted things to be simpler and the "stewarding" group wanted nothing to get in the way of donations. It was remarkably similar to the tensions between sales and engineering in many software firms.
For example, Wikimedia just recently claimed that they can’t chase some political project that critics wanted them to because most of their funds are earmarked-for/invested-in specific projects. So it does happen with US-based tech non-profits to at least some extent.
> $1.5 million over two years would have been quite a lot of money for us, and easily the largest grant we’d ever received.
https://www.fordfoundation.org/learning/library/research-rep...
The hippies writing that software may not be compensated at the level you'd expect given the value they provide, but they'll never go hungry.
[1] LLVM and Linux get more cash than they can spend. GNU stuff is comparatively impoverished because everyone assumes they'd do it for free anyway. Stuff that ships on a Canonical desktop or RHEL default install gets lots of cash but community favorites like KDE need to make their own way, etc... Also just to be clear: node is filled with povertyware and you should be extremely careful what you grab from npm.
"almost" is the load bearing word here, and/or a weasel word. Define what an "economically important project" is.
> Also just to be clear: node is filled with povertyware and you should be extremely careful what you grab from npm.
Is "povertyware" what we call software written by people and released for free now?
Linux, clang, python, react, blink, v8, openssl... You know what I mean. I stand by what I said. Do you have a counterexample you think is clearly unfunded? They exist[1], but they're rare.
> Is "povertyware" what we call software written by people and released for free now?
It's software subject to economic coercion owing to the lack of means of its maintainership. It's 100% fine for you to write and release software for free, but if a third party bets their own product on it they're subject to an attack where I hand you $7M to look the other way while I borrow your shell.
[1] The xz-utils attack is the flag bearer for this kind of messup, obviously.
Essentially "povertyware" as you call it when you consider the trillion dollar companies built on top of them? Now that's way easier: SQLite, PostgreSQL, ffmpeg, imagemagick, numpy, pandas, GTK, curl, zlib, libpng, zxing or any other popular qr/barcode library, etc...
For Linux "all the major contributors and maintainers are on the payroll of one of the big tech interests or a foundation funded by them" is simply not true. It's trivial to prove this by just looking at the maintainers of the subsystems. Making this claim is nonsense to begin with.
Same is true for several major contributors to the Python compiler and subsequent libraries as well.
You will move the goalpost by trying to narrow down what "major contributor" means.
> It's software subject to economic coercion owing to the lack of means of its maintainership. It's 100% fine for you to write and release software for free, but if a third party bets their own product on it they're subject to an attack where I hand you $7M to look the other way while I borrow your shell.
So without knowing anyone you are making a value judgement on the (probable?) lack of ethics? Excuse me?
I can't move the goalpost if you won't produce a ball. Who exactly are you thinking of that needs a job but doesn't have one?
That is not your claim. Your claim is that they "are on the payroll of one of the big tech interests or a foundation funded by them". Which is simply not true.
You can easily find several maintainers of these projects doing this as their part-time hobby project, have cut a deal at work or simply don't work at place that funds Linux development.
I'm not going to call out individual I know the situation and/or their employment history.
This is often the problem with charity in general. It's hard to find good organizations that actually need your money. Great ones self-sustain on their own revenue. Good ones are saturated with donations from their own users. There's just a small sliver of projects that are awesome, and could productively use financial support. From personal experience, identifying these is often far more costly than the act of writing a check.
EDIT: or are you rather thinking about the book Working in Public: The Making and Maintenance of Open Source Software?
From a 2022 email:
> (P.S. I have a new last name! Still transitioning everything over, but I’m now Nadia Asparouhova.)
Here the website of the author: https://nadia.xyz/
We should applaud their donation today, and at another time assess the meager contributions of many companies that should be shamed.
I've worked at a few that use the 'mold' linker to dramatically reduce their build times. Again, very few contribute. In this particular case, I managed to get one former employer to make a donation.
But the list goes on.
Short arms, deep pockets, as the saying goes.
If python wants to require money for updates or for customers over $X in revenue, they can!
If companies don’t want to donate, they don’t have to just as python contributors don’t have to if they’re annoyed at how it’s used.
I find these matters are often more complex than I can understand from a headline but this feels like Anthropic bailed out the PSF because PSF is making bad management decisions, and bailing them out might be a bad long-term play.
Believe it or not, not all researched information is accurate. And even when it is accurate it isn't always interpreted correctly. It is not sufficient to simply research something.
One must also discuss it. That allows revealing what one thinks they know, to help realize what they don't through coordination with others.
That is what discussion is for. If he already had a perfect picture, what would the point of talking about it be? There isn't one.
Drive-by insinuation rather than argumentation.
Not only will they not grant future funds, but they have shown that they will not pay out previously agreed monies, and will even try (with government layers) to pull back funds from groups they have decided "do not align with the governments interests", for however they define that at that moment. There are a long list of court findings that these have been arbitrary and capricious, but every one of those findings (wins) cost the grant receivers a lot of money in court and later fees.
So any money taken from them is incurring a risk. You can disagree with the Python Foundation's calculus on this (saying it was not that large a risk), but please don't pretend that it was not an actual risk.
This is a morally depraved condition, kudos on them for turning it down
a) the huge influx of beginners into IT,
b) lots of intro material available in Python and
c) having a simple way to run your script and get feedback (same as PHP)
To be clear: Haskell is great, but its entire vibe (lazy evaluation, pure functions) is entirely different from what Python's about. Someone who knows C++ or Java has a much bigger gap to jump to pick up Haskell than to pick up Python.
Not really. You can do some basic checking, like ensuring you don't pass a string into where an integer is expected, but your tests required to make sure that you're properly dealing with those integers (Python type hints aren't nearly capable enough to forgo that) would catch that anyway. The LLM doesn't care if the error comes from a type checker or test suite.
When you get into real statically typed languages there isn't much consideration for Python. Perhaps you can prompt an LLM to build you an extractor, but otherwise, based on what already exists, your best bet is likely Lean extracted to C, imported as a Python module. Easier would be to cut Python out of the picture, though.
If you are satisfied with the SMT middle-ground, Dafny does support Python as a target. But as the earlier commenter said: Types are best.
For a lot of the business world, code flexibility is much more important than speed because speed is bottlenecked not on the architecture but on the humans in the process; your database queries going from two seconds to one second matters little if the human with their squishy eyeballs takes eight seconds to digest and understand the output anyway. But when the business's needs change, you want to change the code supporting them now, and types make it much easier to do that with confidence you aren't breaking some other piece of the problem domain's current solution you weren't thinking about right now (especially if your business is supported by a team of dozens to hundreds of engineers and they each have their own mental model of how it all works).
Besides... Regarding performance, there is a tiny hit to performance in Python for including the types (not very much at all, having more to do with space efficiency than runtime). Not only do most typed languages not suffer performance hindrance from typing, the typing actually enables their compilation-time performance optimizations. A language that knows "this variable is an int and only and int and always an int" doesn't need any runtime checks to confirm that nobody's trying to squash a string in there because the compiler already did that work by verifying every read and write of the variable to ensure the rules are followed. All that type data is tossed out when the final binary gets built.
And just a few comments earlier you said:
> Just recently I heard that typed languages are best for agentic programming
Are we not talking about using python (or some alternative) to constrain the behavior of agents?
It's pretty great, because you can run it in debug mode where it will assert-fail if your static type assertions are violated, or in optimized mode where those checks (and the code to support multiple types in a variable) go away and instead the program just blows up like a C program with a bad cast does.
That's not like a widespread/by-default/de-facto standard across the ecosystem, by a wide margin. Browse popular/trending Python repositories and GitHub sometime and I guess you can see.
Most of the AI stuff released is still basically using conda or pip for dependencies, more times than not, they don't even share/say what Python version they used. It's basically still the wild west out there.
Never had anyone "frown" towards me for not using MyPy or any typechecker either, although I get plenty of that from TS fans when I refuse to adopt TS.
I’ve seen it many times. Here’s one of the more extreme examples, a highly-upvoted comment that describes not using type hints as “catastrophically unprofessional”:
https://www.reddit.com/r/Python/comments/1iqytkf/python_type...
Don't read stuff on reddit and use whatever you've "learned" there elsewhere, because it's basically run by moderators who try to profit of their communities these days, hardly any humans left on the subreddits.
Edit: I really can't stress this enough, don't use upvotes/likes/stars/whatever as an indicator that a person on the internet is right and has a good point, especially not on reddit but I would advice people to not do so on HN either, or any other place. But again, especially on reddit, the upvotes literally count for nothing. Don't pick up advice based on upvoted comments on reddit!
If you're working on a project that doesn't use type hints, there's also plenty of frowning, but that's just because coding without a type checker is kind of painful.
Yeah, that obviously makes sense, not following the code guidelines of a project should be frowned upon.
Python typed or untyped feels like a taste / flexibility / prototyping tradeoff; TypeScript vs. JavaScript feels like "Do you want to get work done or do you want to wrap barbed wire around your ankle and pull?" And I say this as someone who will happily grab JS sometimes (for <1,000 LOC projects that I don't plan to maintain indefinitely or share with other people).
Plus, TypeScript isn't a strict superset of JavaScript, so choice at the beginning matters; if you start in JS and decide to use TS later, you're going to have to port your code.
> TypeScript helps paper over like 90% of the holes in JavaScript
Always kind of baffles me when people say this, how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses? I must be doing something very different when writing JS because while those things happen sometime (once or twice a year maybe?), 90% of the issues I have while programming are domain/logic bugs, and wouldn't be solved by TS in any way.
I can just skip the mypy run if I want to do untyped Python. I can't skip adding types if I'm writing TypeScript in most contexts; it's not valid TypeScript syntax. Conversely, I can't add types to JavaScript; it's not valid JavaScript syntax (jsdoc tags and running a static checker over that being a different subject, and more akin to the Python situation).
> how are you actually programming where 90% of the errors/bugs you have are related to types and other things TS addresses
It's the things in the "wat" video. JavaScript, in general, errs on the side of giving you some answer when you try and do something very unusual with types (like add a boolean to a number or a string to an array) over taking a runtime error. TypeScript will fail to typecheck in most of the places where those operations are techincally correct but surprising as hell in the wrong way unless you explicitly coerce the types to match up.
I can name an absolute handful of languages I've used that have that flexibility. Common LISP comes to mind. But in general you get one or the other option.
It’s also a worst-of-both-worlds arrangement, in that you have to do the extra work to satisfy the type checker but don’t get the benefits of a compiled language in terms of performance and ease-of-deployment, and only partial benefits in terms of correctness (because the type system is unsound).
AFAIK the Dart team felt this way about optional typing in Dart 1.x, which is why they changed to sound static typing for Dart 2.
That was an okay tradeoff for humans writing code as it enables things like the squiggly line as you type for basic mistakes, automatic refactoring, etc. But that stuff makes no difference to LLMs.