On 19Feb2019 1212, Stefan Behnel wrote:
So, yeah, I'm happy with the status quo, and a bit worried about all the moving around of declarations and that scent of a sword of Damocles hanging over their potential confinement. IMHO, things should just be public and potentially marked as "unstable" to advertise a risk of breakage in a future CPython X.Y feature releases. Then it's up to the users to decide how much work they want to invest into keeping up with C-API changes vs. potentially sub-optimal but stable C-API usage.
Unfortunately, advertising a risk of breakage doesn't make the break less painful when it happens. We'd rather avoid that pain by preemptively breaking (at a major version update, e.g. 3.8) so that minor breaks (e.g. between 3.8.2 and 3.8.3) don't cause any problems at all. And if we preemptively break, then we can also preemptively add functions to cover what direct memory accesses previously used to do. And it's not up to the users - it's up to the package developers. Most of whom optimise for their own ease of life (as someone who supports Windows users, I'm well aware of where package developers cut painful corners ;) ). The only choice users get in the matter is whether they ever update Python, or if they switch to a language that is more respectful toward them. For what it's worth, the users I've been speaking to recently are *far* more concerned about being able to update Python without things breaking than they are about runtime performance. Cheers, Steve