Yes, the SC thinks this is a good idea. We should probably take both the ‘python’ and the ‘cpython’ org names. As a general policy on which is used for what, here’s what we have in mind:
cpython: for development tools that are tied fairly closely to CPython development. This could for example include blurb and cherry-picker. Users generally shouldn’t have to care except for developing CPython itself (although that doesn’t mean the tools necessarily have to be unusable for anyone else).python: for general-audience projects that are maintained the Python Core Devs. An example for this category would be tzdata.
In both cases it should only be used for packages that are ostensibly collectively maintained by the Core Developers (even if only one or two people are actively doing so), as opposed to packages that are maintained by people who also happen to be Core Developers but are publishing the package independently. The python and cpython orgs would put the responsibility and authority on the Core Developers as a whole, and we want to make sure we reflect those expectations in the policy.
That said, the SC doesn’t have a lot of experience with PyPI orgs, so we want to make sure this policy makes sense to the Core Devs it would affect, as well as PyPI maintainers and potential users. Please let us know what you think.