Brett Cannon
Brett Cannon, a Python core developer, writes about Python's history, language internals, packaging tools, and the social side of open source maintenance.
What HN says
Commenters recommend his Syntactic Sugar series for how Python features work and cite his posts on open source maintainer burnout and expectations.
Stats for nerds
100HN people shared it
157linked in comments
2.6Kstory points
Dec 2023last shared
Top posts on HN
- 1Why Python 3 Exists7 people · 420 points · first shared 2015 · 266 comments on HN
- 2Why to use ‘python -m pip’6 people · 266 points · first shared 2019 · 135 comments on HN
- 3What is the core of the Python programming language?4 people · 237 points · first shared 2020 · 129 comments on HN
- 4Taking a month off from OSS volunteering4 people · 237 points · first shared 2016 · 179 comments on HN
- 5What the Heck Is Pyproject.toml?4 people · 133 points · first shared 2020 · 194 comments on HN
- 6Why it took 4 years to get a lock files specification2 people · 125 points · first shared 2025 · 93 comments on HN
- 7How I stay happy making open source software3 people · 117 points · first shared 2015 · 34 comments on HN
- 8Where are we in the Python 3 transition?3 people · 117 points · first shared 2016 · 132 comments on HN
- 9Selecting a programming language can be a form of premature optimization2 people · 91 points · first shared 2021 · 309 comments on HN
- 10The history behind the decision to move Python to GitHub13 people · 84 points · first shared 2016 · 27 comments on HN
What HN people wrote when they linked it
- urygaNov 2019
the coroutines are run sequentially by an "event loop"/"coroutine runner" that wakes them up and lets them run for a bit when appropriate, kind of like an OS's scheduler (on a single core machine). if the runner is the OS, `await foo(..)` is kind of like a syscall, where the coroutine is suspended and control is handed back to the runner to do whatever is requested.
i guess the difference from normal threads (preemptive multitasking) is that you explicitly mark your "yield points" – places where your code gives control back to the runner – with `await` (cooperative multitasking). some believe that this makes async stuff easier to reason about, since in theory you can see the points where stuff might happen concurrently
honestly i'm out of my depth re: async IO, haven't used it all that much :/ but if you're comfortable with python and want to dig into the mechanism of async/await, i really recommend this article: https://snarky.ca/how-the-heck-does-async-await-work-in-python-3-5/
it's long, but i found it very helpful – it actually explains how it all works without handwaviness. at the end the author implements a toy "event loop" that can run a few timers concurrently, which really made it click for me!
- cx1000Feb 2017
Sounds to me like you don't understand how git works. If GitHub shuts down, people will just use a different server to host their repository, such as gitlab.
The guy in charge of making the decision weighed the fact that it's closed source, and it still won.
> But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform.
In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github
https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/
- epistasisAug 2020
I 100% agree on this. But it's been pretty hilarious on how obstinate tool makers are about changing to Python's new pyproject.toml [1]
Python packaging is a bit of a mess already, so when I recently started a new small package I wanted to choose tooling that would not clutter, but a fair amount of tool makers were reluctant to allow code into their repo that would use the unified toml rather than a ton of separate file.
.config is probably a better solution than a single top level toml, IMHO, but far more important is doing something unified rather than continuing the pollution of the top-level namespace, which merely obscures the project structure.
[1] https://snarky.ca/what-the-heck-is-pyproject-toml/
- jonawesomegreenFeb 2019
Open source is hard. Being a maintainer is hard. I've seen a lot of good people burn themselves out trying to maintain / contribute to open source software.
I think this is a great blog post / talk (not mine) about the topic:
https://snarky.ca/setting-expectations-for-open-source-participation/"Here's a bit of real talk for people: I think working in OSS has made me more bitter and short-temperated".
Best wishes to the maintainer, hopefully time gives some perspective on the problems in the community and perhaps some ways forward.
- brettcannonApr 2020
People would love to see that happen, but it requires time and effort from people to build such a solution. Some people are trying, e.g. https://pyoxidizer.readthedocs.io/ and https://briefcase.readthedocs.io/ as well as stalwarts like PyInstaller and such.
But as I said, it takes time and effort and there's only so much of that when it's being done by volunteers in their evenings and weekends.
And as an aside, I would suggest teaching them `python -m pip` over `pip3`: https://snarky.ca/why-you-should-use-python-m-pip/.
- julienpalardSep 2022
It's a good habit which ensures pip runs with the same interpreter as your `python` command.
One example (but there's many): On Windows a `pip install --upgrade pip` can't work as the OS would lock the `pip` executable, while a `python -m pip install --upgrade pip` works as the OS would lock python instead.
I also encontered environments (CI runners, things like this) with `python` and pip installed, installed but no `pip` shortcut.
More: https://snarky.ca/why-you-should-use-python-m-pip/