# Making \`PyObject\` opaque in the limited API

**URL:** <https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206>\
**Category:** Ideas\
**Tags:** c-api\
**Created:** [January 15, 2025, 9:48am UTC](https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206 "2025-01-15T09:48:49Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![alex\_Gaynor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/alex_gaynor/32/17_2.png) [@alex\_Gaynor](https://discuss.python.org/u/alex_Gaynor)\
**Post date:** [January 15, 2025, 3:35pm UTC](https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206/2 "2025-01-15T15:35:28Z")

</div>

> [@encukou](#):
>
> I consider building twice OK: I’ve been convinced that stable ABI shouldn’t be about building _exactly once_, but about building for a _range_ of versions. See [cryptography](https://pypi.org/project/cryptography/44.0.0/#files) which currently builds for cp37-abi3 and cp39-abi3. Other projects might build a version-specific (optimized) wheel for, say, `cp313` and cover the rest with `abi3`.

Yeah, just to state this explicitly from the PyCA maintainers perspective, as long as we have O(1) builds, that’s ok. What we can’t/won’t do is O(n) where we need new builds for every Python release.

My main piece of substantive feedback is that for those of us working in non-C extension modules (Rust, in our case), API compatibility doesn’t do a ton, so figuring out what the desired ABI story is is incredibly important to us.

---

_[View the full topic](https://discuss.python.org/t/making-pyobject-opaque-in-the-limited-api/77206)._