# Python 3.13 alpha 1 contains breaking changes, what's the plan? **URL:** \ **Category:** Core Development\ **Tags:** c-api\ **Created:** [October 30, 2023, 7:02am UTC](https://discuss.python.org/t/python-3-13-alpha-1-contains-breaking-changes-whats-the-plan/37490 "2023-10-30T07:02:09Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\ **Post date:** [October 30, 2023, 10:16am UTC](https://discuss.python.org/t/python-3-13-alpha-1-contains-breaking-changes-whats-the-plan/37490/5 "2023-10-30T10:16:28Z")
> [@scoder](#): > > The amount of breakage is so huge that I’m personally giving up on fixing it. I’d rather start using the internal APIs in Cython than try to make things work efficiently with the public ones again. Because [the changes](https://discuss.python.org/t/c-api-my-plan-to-clarify-private-vs-public-functions-in-python-3-13/30131/9) remove the private functions from the Python library (they are no longer being exported), you can only do this by copying the internal API’s sources verbatim into Cython generated C code (either directly or via some `#include`). Victor has a point in claiming that private Python C API should indeed be private, but his approach feels too radical. At the very least, a PEP should have been written and approved by the Steering Council prior to committing the changes, so that the Python community of extension writers becomes aware of the intended change and gets a chance to participate in the discussion. --- _[View the full topic](https://discuss.python.org/t/python-3-13-alpha-1-contains-breaking-changes-whats-the-plan/37490)._