Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?
Si tu parles de Python 2 vers Python 3, il y a des outils et beaucoup de documentations pour migrer vers Python 3.
Mais je pense que tu veux dire version 2.n vers 2.n+1. Or je n'ai jamais eu de soucis dans ce sens. Je joue plutôt à essayer de rendre compatible Python 2.n-1 un code écrit pour 2.n, et il y a pas mal d'effort dans ce sens (ex: multiprocessing existe pour Python 2.4 et 2.5). Je lis souvent que Python casse la compatibilité, or j'ai souvent vu du code Python 2.4 tourner avec Python 2.5, 2.6 et 2.7, mais jamais de code qui ne passe pas.
Parfois, Python fait des blagues : genre le module md5 est marqué comme désuet dans Python 2.6 puis finalement n'est pas supprimé dans 2.7. Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Selon moi, l'API Python est trop stable, ça serait sympa de parfois faire table rase pour nettoyer les erreurs du passé. Ça a été fait en profondeur dans Python 3, mais ça serait pratique de pouvoir le faire petit à petit. En pratique, dans Python 2, quand l'API évolue, l'ancienne est conservée. Exemple : le module threading a plein de fonctions et méthodes avec des noms en double (ancienne / nouvelle convention).
Maintenant, comme l'a écrit Antoine : je serai intéressé d'avoir un exemple d'incompatibilité entre des versions N et N+1.
[^] # Re: Pas trop de clichés SVP
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 4.
Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?
Si tu parles de Python 2 vers Python 3, il y a des outils et beaucoup de documentations pour migrer vers Python 3.
Mais je pense que tu veux dire version 2.n vers 2.n+1. Or je n'ai jamais eu de soucis dans ce sens. Je joue plutôt à essayer de rendre compatible Python 2.n-1 un code écrit pour 2.n, et il y a pas mal d'effort dans ce sens (ex: multiprocessing existe pour Python 2.4 et 2.5). Je lis souvent que Python casse la compatibilité, or j'ai souvent vu du code Python 2.4 tourner avec Python 2.5, 2.6 et 2.7, mais jamais de code qui ne passe pas.
Parfois, Python fait des blagues : genre le module md5 est marqué comme désuet dans Python 2.6 puis finalement n'est pas supprimé dans 2.7. Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Selon moi, l'API Python est trop stable, ça serait sympa de parfois faire table rase pour nettoyer les erreurs du passé. Ça a été fait en profondeur dans Python 3, mais ça serait pratique de pouvoir le faire petit à petit. En pratique, dans Python 2, quand l'API évolue, l'ancienne est conservée. Exemple : le module threading a plein de fonctions et méthodes avec des noms en double (ancienne / nouvelle convention).
Maintenant, comme l'a écrit Antoine : je serai intéressé d'avoir un exemple d'incompatibilité entre des versions N et N+1.