Même aux mises à jour mineures ? Tu as un exemple ?
À toutes les versions, il y a un changelog très bien fait.
Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
Par exemple, le changement des règles de visibilité des variables dans python 2.1: http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
Les autres versions aussi ont fait des changements incompatibles.
2.6 a supprimé les exceptions chaîne de caractères.
2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2: http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).
[^] # Re: C++, un langage moderne ?
Posté par NanoTech . En réponse à la dépêche C++ 0xB enfin finalisé ?. Évalué à 2.
À toutes les versions, il y a un changelog très bien fait.
Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
Par exemple, le changement des règles de visibilité des variables dans python 2.1:
http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
Les autres versions aussi ont fait des changements incompatibles.
2.6 a supprimé les exceptions chaîne de caractères.
2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).