AFAIK pypy improvements also led to cpython compact dictionaries (which led to dictionaries being ordered) and many many cpython performance improvements (the most recent one being LOAD_ATTR caching, with huge performance gains).
I wonder if sponsoring pypy instead of the PSF might be a way for people that want "a focus on performance improvements, instead of fancy features" to vote with their wallets
Going by https://www.python.org/psf/annual-report/2020/ , 75% are running the annual conference, 12.6% grants open to _anyone_, and 3.8% maintaining a central registry primarily staffed by volunteers, and I imagine paying for quite a sizeable set of origin servers at this stage.
As for the PyCon expenditure, it's certainly the kind of thing I'd never attend, but there can be no doubt the existence of the conference has strengthened and grown Python's user base, and it is open to everyone should they wish to attend. Meanwhile, $97k annual to operate a package registry with literally millions of downloads per month that tens of thousands of companies depend on sounds like an amazing bargain to me.
Speaking as someone who had a core role in organizing PyCon US a decade+ ago and was active with the PSF for some time, I’ve never seen an organization more dedicated to good stewardship and inclusiveness at scale. I’m sure there are other great examples but the PSF was always commendable.
PyCon was always meant to be affordable for as many people as it could be - via low prices and financial aid for many. Those conferences helped create many of the relationships that drove key parts of the Python ecosystem. In addition, there are/were typically dedicated time for code sprints following the main conference. Important work happened there, often for key parts of the Python codebase or key libraries. While the budget numbers don’t say explicitly “development support” people shouldn’t presume PyCon does nothing for the language itself. Open Source conferences are not like commercial conferences. It’s community driven rather than marketing driven. That difference matters.
It was a smaller world when I was involved but it was and still is something special.
#standardSQL
SELECT EXTRACT(HOUR FROM timestamp) hour, COUNT(*) AS num_downloads
FROM `the-psf.pypi.file_downloads`
WHERE DATE(timestamp)
BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND CURRENT_DATE()
GROUP BY hour
ORDER BY num_downloads
Gives us 6.956 billion downloads in the past 30 days
With hour 15 clocking in at around 2,964 requests/sec -- mean. This is still not representative of peak instantaneous traffic, which I'd hazard a guess is somewhere closer to 10x that number.
Now factor in the 'usual' case where the CDN absorbs 70% of this, and you're still left with a service that is non-trivial to run and support 24/7. PyPi manages to only have a few small downtimes per year.
Hadn’t thought to look up more precise numbers, and the comment on CDN is good one. It’s an example of where smart choices in the client (pip) could keep the backend (PyPI) scalable.
Total expenses for 2019 were a bit under $3.7m. "Program service expenses" were $2.6m, about 70% of total expenses. Of this $2.2m, 75.3% was spent on PyCon. So overall, around 53% of PSF spending in 2020 went to PyCon ($1.9m). In 2018, it was around 57%.
The next-biggest expense was staffing ($694k), at around 19% in 2019.
I wonder if sponsoring pypy instead of the PSF might be a way for people that want "a focus on performance improvements, instead of fancy features" to vote with their wallets