Okay so I am putatively a #Python #ThoughtLeader ™ so perhaps I should go through and give this a non-jokey read-through, and share some impressions: https://lp.jetbrains.com/python-developers-survey-2024/
I really appreciate that they do these every year.
Next we see where users learn about new Python stuff, and it's a real good news / bad news situation.
First, the good news: 41% of python users find out from Python.org which is great. It means we have a dis-intermediated first-party comms channel to the community that actually matters. That is great. Getting the word out about changes is *rough* and if that many people are checking Python.org we actually have hope!
The work/personal breakdown is a little hard to read, but it's clear that most people who use Python for work are also using it for other stuff, so the ecosystem is still dynamic enough that we are featured prominently on Good Screen and not just on Bad Screen.
Topic application looks about how I'd expect, data science, ML, web dev dominate, lots of academics. Desktop development still going strong, and flat (despite overall growth) at 16! I am always relieved to see a big diversity here.
For unit testing, dang, pytest is even more of an 800lb gorilla than I thought. 53%, with the runner-up being "None" at 36% (😬). Quite surprised to see Tox down at 5% and Nox not even visible in the rankings, presumably down in that 2% "other". More people, by a wide margin, use doctest than Tox; that's a big surprise. I can't remember the last time I saw a doctest in the wild, at least, in new code.
This is a real "and quartz, of course" situation for me.
AWS sells a lot of cloud servers. Microsoft is really trying to catch up. A pretty strong minority still don't use cloud providers at all. People use virtualenvs a lot, followed by Docker. Yawn.
Things that I wish were surprising: 9% code directly in prod, 19% code directly against the system interpreter with no venv. At least these each declined by 1% this year. Let's just gently keep that trend going.
Next…
On to CI systems: lots of github actions users, but glad to see we have not collapsed into a monoculture here. at 35% to 22%, gitlab CI is hot on their heels, and plenty of people still remember how to use Jenkins if it comes to that.
Interesting, and a little sad, to see that Buildbot doesn't even show up in here any more, but, so it goes.
Interesting to see requirements.txt is so much more popular than pyproject.toml. This suggests a documentation / socialization failure. This smells like people are just shoving their git repo into (at best) containers and managing its setup and deployment with shell scripts, rather than putting it into a proper envelope where a wheel gets built and deployed along with all the dependency wheels.
Maybe wider adoption of uv could push this up as well; manually populating requirements.txt is so sad
Wide (>50%!) awareness of trusted publishers, only a couple of years after their launch, is great. Lots of people using the github action.
(Ugh, I really need to make the time to do this consistently for all of my projects as well… I still have locally-push-to-PyPI workflows for most things just due to muscle memory and laziness.)
Whew. Okay, I don't have anything to say about the employment stats section, that all just looks like pedestrian tech-industry info that doesn't particularly tell me anything interesting about the Python community. So that's it. Thanks for following along. Main takeaways for me here are:
1. big community growth year over year
2. tool and ecosystem diversity looks pretty healthy modulo a couple of worrying trends
3. weird that people aren't using sphinx
4. diversity is still a big problem
@wlonk That, and having a Makefile at the top of the generated docs dir.
(It's probably the right tool for the job, but it feels anachronistic.)
@glyph I keep coming back to that 50% of respondents have less than 2 years of Python. The respondent base seems to have missed, well, most of the community.
There was an interesting bit looking at the Django numbers. It showed 93% cross-usage between Django and DRF — so it roughly all APIs, at a glance — but we know from PyPI installs that DRF is used in ≈50% of all Django projects. So where's the other half? Not represented.
Or something 🤷
@esoteric_programmer it also supports google cloud and ActiveState https://docs.pypi.org/trusted-publishers/adding-a-publisher/ so there’s a reasonable amount of diversity there.
If you want to operate a service that can meet their security requirements, I am sure you could convince them to add you too :)
every sign is a story and this one says something *bad* happened here
@glyph I wrote a thing a few years back about dependency management that's been mildly popular. I should probably give it some light updates, but the tl;dr is what I do -- and what we do at my day job -- is use PDM as a convenient frontend, which stores direct dependencies in pyproject.toml, and then export to a pinned+hashed requirements file to pip install inside containers.
In general I don't yet trust any third-party installer in my containers, and I don't know if I ever will; the only update I foresee coming is exporting to pylock.toml once pip gains support for installing from it.
@glyph Huh, does that make me more megalomaniacal than you, since I *did* write a decent chunk of it? :)
As far as the second part goes, there's a reason one of the first links from the landing page is to the software deployment overview in https://packaging.python.org/en/latest/overview/. The external links in that overview could do with some modernisation, though (albeit of debatable benefit, as how many people *really* want to read a long discourse about how their problem is just one point along a complex spectrum?)
@glyph The fact that a bunch of projects don't use sphinx and use a bunch of _much worse for the task_ tools in its place bothers me so much some weeks.
And sphinx + myst basically solves the only thing I used to be apologetic about around the use of rst. I think rst is great but it's a huge hill for most folks.
@astraluma @glyph Yeah, the thing to know is that myst only makes the most simple rst stuff markdown. Once you need rst only features, you're writing rst in code blocks in markdown and it's. . . less good.
If you're not _using_ the advanced features, Myst is great. Once you want them, you just want to go back to rst. (Good news: Technically, you can use them side by side and just migrate files to rst as needed.)
@glyph @astraluma @pathunstrom you beat me to the question; superficially that sounds like it adds a layer of complexity and code to little benefit.
For my part, I've moved over to mkdocs for many things because of the developer tooling. The auto-updating dev server is a godsend when iterating on documentation, enough so that it's worth the pain of dealing with mkdocs-material.
@astraluma @glyph @pathunstrom that's ... actively tempting.
(I admit I also struggle to write some simple things in RST -- inline code snippets are, IIRC, a pain in the ass, and links are completely unintuitive compared to markdown, so there's a few other barriers, but this is a huge step. Thanks!)
@offby1 @glyph @pathunstrom Oh yeah, full URL links in RST are objectively worse.
But also, when writing documentation, I find I'm rarely making links by URL. I'm much more often making links to functions or concept or other sections or via intersphinx. And I think doing those in MyST is weird and awkward.
As for ``foo`` vs `foo`, i just don't care.
@glyph I am a Sphinx user (privately), but from my experience:
The latter is surprisingly common, with people telling me they don't document their Python codes because they find the docstring syntax ugly?
EDIT: I've realized after posting this that the last part makes little sense: docstrings ≠ Sphinx. However, I think that docstrings are the entrance into Sphinx for many (they were for me), but if one doesn't write docstrings, they'll probably never get the motivation to write full fledged docs, too
Any time I see a readthedocs link I just know I am going to get useless autogenerated documentation that doesn't tell me anything that I couldn't have guessed from the name of the function and I'm going to wear out my scroll wheel scrolling past enormous docstrings that just repeat what the function definition says so I can read the code to figure out what it actually does. As such I have never been motivated to look in to how they are made.
Glyph
kit 🌬️🌦️
Judy2k
Emile Snyder
Hynek Schlawack
alys
Efi (nap pet) 🦊💤
aeva
Carlton Gibson
the esoteric programmer
Matt Campbell
James Bennett
cassie
Alyssa Coghlan
Ölbaum
Piper Thunstrom
AstraLuma
Chris is.
Nikita Karamov
Alistair Buxton
mcc