Le drapeau `--max_process` de deux scripts passe par ce pool, et il ne
tournait plus du tout. Deux retraits d'API le traversaient : `loop=` a quitté
`asyncio.wait` en 3.10, où le passer lève un TypeError, et
`asyncio.get_event_loop()` lève hors d'une loop en marche depuis 3.14, où il
ne faisait qu'avertir — donc la classe n'était même plus instanciable, alors
que l'aide annonce toujours l'option.
La loop n'est plus créée à l'instanciation mais à l'exécution, et `close` ne
ferme que celle que la classe a ouverte : une loop reçue en argument
appartient à l'appelant, qui compte encore dessus. Vérifié : 7 tests sur de
vraies coroutines, et les deux appels d'origine lèvent toujours à part.
--- EN ---
The `--max_process` flag of two scripts goes through this pool, and it no
longer ran at all. Two API removals crossed it: `loop=` left `asyncio.wait` in
3.10, where passing it raises a TypeError, and `asyncio.get_event_loop()`
raises outside a running loop since 3.14, where it merely warned before — so
the class was not even constructible, while the help still advertises the
option.
The loop is no longer created at construction but at run time, and `close`
only closes the one the class opened: a loop received as an argument belongs to
the caller, who still counts on it. Checked: 7 tests on real coroutines, and
both original calls still raise on their own.
Assisted-by: Claude Opus 5
