[Python-Dev] Making PyInterpreterState an opaque type

Steve Dower steve.dower at python.org
Tue Feb 19 15:40:42 EST 2019

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.


More information about the Python-Dev mailing list