Donald Stufft <don...@stufft.io> added the comment: The fundamental problem is that unless you're closely following the development of python-dev, it's really really easy to use a provisional module without knowing that you are.
Take asyncio for example, as far as I can tell the documentation that noted it was provisional was a single, near invisible (light grey on a white background) call out at the very top of a single page in the documentation. This is made especially hard when you have people giving talks at PyCon encouraging people to use this, libraries of the code that don't mention that asyncio is provisional, so unless you're directly using asyncio you might not even be aware that they're using a provisional API at all. This has the effect that by including these APIs and make the fact they are provisional practically unnoticeable, it pushes the pain of dealing with changes onto library authors who have their own users asking them to integrate with these features. Putting library authors in the position of either having to opt-in to a provisional API and hope it doesn't change, having to scramble to keep up with changes in new minor releases, or having to relitigate why they're not going to support a provisional API. Ironically, as we found with web APIs, releasing provisional APIs can actually make things worse for end users, because people will expect the usage of the APIs as if they were covered under the normal contract, but the developers of those APIs feel empowered to make more drastic changes. The long development time of CPython makes this even worse (it was ~2 years from the release of 3.4.0 and 3.6.0 for asyncio to become non provisional, longer if you count alpha/beta/etc) because people want to use the new stuff, but they have to wait a fairly long time to be "allowed" to do it, all the while the general ecosystem consensus is "just do it and ignore the warning, if you noticed the warning at all". Ultimately, the provisional status doesn't reduce the pain of getting APIs wrong, it just shifts the pain from CPython's developers to the software developers writing stuff that depends on CPython but that they don't directly control the execution environment (e.g., all the OSS libraries and applications on PyPI). A proposal like this helps alleviate some of that pain by creating additional barriers to entry to make end users less likely to use it unless they understand what they're asking for. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
