Uther (./5023) :
Alors je suis pas un expert python, loin de là donc n’hésite pas a me corriger si j'ai faux, mais de ce que j'avais compris, il est problématique de faire que un code conçu spécifiquement pour du Python 2 s’appuie sur des bibliothèques conçues spécifiquement pour du Python 3, et vice versa, sans modification spécifiques dans le code de l'un ou de l'autre.

Si tous tes codes fonctionnent avec Python 2 et Python 3, il n'y a aucun souci à utiliser Python 2 ou Python 3. Mais c'est sûr qu'à partir du moment où un code utilise des spécificités de Python 2 ou 3, tu es obligé d'utiliser le bon interpréteur.

Rust n'a pas ce genre de problème :[...]

Il y a deux différences fondamentales : le côté compilé de Rust d'une part, et d'autre part Rust ne correspond qu'au langage (et éventuellement au compilo) alors que Python fait référence à la fois au langage, à l'interpréteur et à la bibliothèque standard.
En pratique, très souvent le problème viendra de la bibliothèque standard.
Imaginons que ton code utilise class_A de la bibliothèque standard, au travers de lib_A (et pensé pour la bibliothèque standard de Python 2) et de la lib_B (pensé pour la bibliothèque standard de Python 3) et qu'il y a eu un changement incompatible entre les deux versions, tu auras forcément des problèmes. Je pense que tu auras le même problème en Rust si tes dépendances se basent sur des versions incompatibles de la libstd.

flanker (./5020) :Par ailleurs, ce que tu aurais souhaité aurait au contraire mécaniquement ralenti encore plus la transition qui a été déjà trop lente : si tu n'as aucune incitation à migrer ton code (vu que c'est transparent de le garder dans une vieille version), tu ne risques pas de le migrer.

C'est vrai que l'incitation a migrer est moins forte, mais c'est aussi le cas de l'incitation à ne pas migrer. [/quote]
Je ne comprends vraiment pas ce que tu veux dire.
Tu reproches de ne pas avoir assez d'incitation à migrer en prolongeant le maintien de Python 2, et tu proposes d'encore moins inciter à migrer en gardant la compatibilité avec Python 2.

C'est beaucoup plus simple pour un mainteneur de crate de prendre la décision de migrer quand l'on sait qu'on aura pas besoin de se soucier de problèmes causés par les dépendances et qu'on en causera pas a ceux qui dépendent de nous.

Mais ce n'est pas faisable à cause de la bibliothèque standard.

Dans la pratique quasiment toutes les crates Rust maintenues font la transition dans les mois qui suivent la sortie d'une édition.

Mais c'est pareil en Python : les codes activement maintenus font la migration très vite, sauf quelques rares exceptions (liées au réseau et le problème u"" / "", rendant la migration de grosses bases de code impossible à faire automatiquement et progressivement). Les passages de versions mineures sont généralement transparentes.

Quant au code qui n'est plus maintenu, il ne risque pas de migrer, en effet.