This is a generic workflow question that isn’t about Python so much as project management in general.
While perusing documentation, I saw this:
In Python 3.16, AnyStr will be removed from typing.__all__, and deprecation warnings will be emitted at runtime when it is accessed or imported from typing. AnyStr will be removed from typing in Python 3.18.
And that got me to wondering:
How does the team guarantee that actually happens?
Are there tests already in place that fail if the above does not happen? Project dashboards? Tribal knowledge? Check lists?
If this is already documented anywhere, sorry, I missed it. Pointers appreciated!
Thanks, but typing is just a random example that triggered these thoughts and this question is not meant to be specific to that module. Instead, a question about overall process that I could perhaps learn from.
There are over 600 modules in the code base. I presume that more than one has a deprecation going on.
But, continuing to use typing as a handy example, a quick glance on the source tree on github did not turn up any tests regarding say tests for the exists of AnyStr being visible in typing.__all__ if sys.version_info[:2] >= (3, 16). So that is not likely to cause anything to fail once the minor version is bumped.
I also did not see any issue labels for 3.16, so that isn’t likely a checklist.
What helps eliminate the “bus factor” when there is a single interested party in something happening?
The “to be removed in” tracking is done in two places in the documentation rather than in the issue tracker:
the individual deprecation notices
the list of pending deprecations in the What’s New document
Indefinite deprecations (where we have no plans to remove the old way of doing things, but recommend avoiding the old approach in new code) don’t get listed.
If I understand properly, while that change suggests GitHub milestones, those are currently not used by the main project. Correct? (I suspect the version labels would suit the same purpose)
And similar processes would be used for other substantial changes? I’m think like changing out or tweaking various subsystems that are not so much deprecations as implementation changes (say, of instances, allocators, garbage collectors, system tunings, etc).
There is no standardised process for tracking larger changes that won’t reasonably fit in a single PR.
Depending on the scale of the change, it may vary from something as simple as a task list in a single GitHub issue (frequently used for PEP implementations) to an entire separate project with its own dedicated issue tracker (such as the Faster CPython project).
It all depends on the preferences of the people doing the work for any given change.
Edit: one practice that has become more common since the SC was established is the publication of informational PEPs regarding large scale refactorings. This allows the SC to give in principle approval for work to be done in the main CPython repo, while leaving the exact technical details to the implementation issues and PR reviews.