PyPI aceptó a finales de junio el PEP 752, un mecanismo que permite a una organización reservar un prefijo de nombre de paquete y bloquear nuevas subidas que coincidan con él, salvo que las envíe el titular de la reserva. Los paquetes ya existentes quedan excluidos de la norma. La medida busca frenar la suplantación: distribuir malware bajo nombres como google-cloud- o apache-, que anteponen la marca de un proveedor conocido a un programa malicioso. Los ejemplos del propio PEP son google-cloud-, opentelemetry-, apache-airflow-providers- y types-, cuatro prefijos que en PyPI agrupan 264, 271, 154 y 1.295 paquetes respectivamente, publicados casi en su totalidad por Google, el proyecto OpenTelemetry, el equipo de Apache Airflow y los maintainers de typeshed. La reserva formaliza una práctica ya consolidada.
Un análisis sobre 912.665 paquetes de PyPI muestra 13.934 prefijos compartidos por cinco o más paquetes. El mayor es django-, con 17.450 paquetes de miles de autores a un ritmo aproximado de mil al año desde 2010. Otros como flask- (2.815), pytest- (2.137) o sphinxcontrib- (370) responden a convenciones de plugins abiertas: cualquiera publica su extensión siguiendo el patrón que el proyecto anfitrión documenta. collective.*, de la comunidad Plone, suma 1.436 paquetes desde 2008.
La reserva de prefijos no es nueva. NuGet la puso en marcha en octubre de 2017 y añadió con el tiempo la delegación de subprefijos y las reservas públicas, funcionalidad que un borrador inicial del PEP 752 incluía como espacio de nombres abierto y que fue retirada por considerarse innecesaria. Un repaso a siete registros (PyPI, crates.io, RubyGems, Hex, Hackage, npm y NuGet) revela que entre un tercio y dos tercios de los paquetes de cada uno comparten el primer token con al menos otros cuatro, y que el patrón dominante en los registros es el de las convenciones abiertas de plugins.