# Remove (again) private APIs which now have new public replacement? **URL:** \ **Category:** C API\ **Created:** [October 16, 2024, 10:30am UTC](https://discuss.python.org/t/remove-again-private-apis-which-now-have-new-public-replacement/68081 "2024-10-16T10:30:00Z")\ **Posts on this page:** 1\ **Showing post:** 15
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [February 4, 2025, 11:04am UTC](https://discuss.python.org/t/remove-again-private-apis-which-now-have-new-public-replacement/68081/15 "2025-02-04T11:04:15Z")
It seems that for some of the APIs, the main reason to remove them is to allow us to change the internals – to add new features, optimizations, or simplifications. IMO, that’s a good reason to remove them _at the time when we need to make the change_. I don’t think pre-emptively deprecating these, with a removal date set a few releases in the future, works well. If the internals need to be changed sooner, we’re either blocked or break the API before the documented time. If we don’t get around to changing the internals, but remove the API anyway, we break users without a good reason. Would it be better to mark them as deprecated, but _without_ a planned removal date? Then, they can be removed when necessary. (Like any private API, of course – but with a warning and with porting notes. Good porting notes in particular should help to ensure that it’s _possible_ to switch to supported APIs, and make the switch as painless as possible.) --- _[View the full topic](https://discuss.python.org/t/remove-again-private-apis-which-now-have-new-public-replacement/68081)._