[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.
Cheers,
Steve
More information about the Python-Dev
mailing list