Cela veut dire que de la version 2.1 à la version 2.2 (...) ajoute également des nouvelles structures.
En quoi est-ce un problème ? Ton code 2.1 fonctionnera toujours. Tu n'as pas à modifier ton code.
que de la 2.6 à la version 3.0, il n'y a plus de compatibilité
C'est un choix : la version 3 brise la compatibilité pour corriger les erreurs du passé.
Qu'à partir de maintenant, il faudra réécrire les programmes pour être compatible 3.0
Non, la branche 2.x continue d'être maintenue et il n'est pas prévu d'arrêter son développement. Pour information, la branche 2.x est la branche principale (trunk), contrairement à la branche 3.x qui est à part (branches/py3k).
Cela veut aussi dire que la référence c'est l'implémentation de guido et que personne d'autre ne peut être sur de correspondre à la spec
Sais-tu qu'il existe d'autres implémentations de Python que CPython (l'implémentation de référence écrite en C) ? IronPython (.NET), Jython (Java), PyPy (Python), ... Il existe une ÉNORME suite de tests pour vérifier la compatibilité (Lib/test/*py : ~430 fichiers contenant chacun plusieurs dizaines de tests). On s'en sert pour mesurer le niveau de compatibilité avec CPython : PyPy est proche du 100% (genre 99% je crois) alors que PyPy a été réécrit depuis zéro.
Si on prend plus précisément l'exemple des versions 2.x et les sections "Porting to Python 2.x" : (...)
Je connais mal ces documents, mais c'est souvent des corrections de bug (disons des comportements qui n'étaient pas prévus). On peut voir ça comme une rupture de la compatibilité (et oui, c'est le cas). Mais c'est voulu pour augmenter la qualité des language (et des logiciels écrit en Python). Un langage trop laxiste (allez, disons PHP) est source de problèmes difficiles à corriger et comportements inattendus.
Les changements sont quand même mineurs et rapides à corriger. D'ailleurs, c'est des cas particuliers qui impactent peu de projets.
J'ai écrit du code pour Python 2.4 (projet de +25.000 lignes) : il fonctionne sur Python 2.5 et 2.6 sans que j'ai eu à le modifier.
Bon, je peux me tromper, j'ai peu d'expérience dans la migration d'un gros projet 2.n => 2.(n+1). Je sais que Zope est bloqué en Python 2.4 par exemple. Il me semble qu'il y a un projet de migration vers 2.5 (alors que la dernière version stable de Python est la 2.6 :-/).
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 4.
En quoi est-ce un problème ? Ton code 2.1 fonctionnera toujours. Tu n'as pas à modifier ton code.
que de la 2.6 à la version 3.0, il n'y a plus de compatibilité
C'est un choix : la version 3 brise la compatibilité pour corriger les erreurs du passé.
Qu'à partir de maintenant, il faudra réécrire les programmes pour être compatible 3.0
Non, la branche 2.x continue d'être maintenue et il n'est pas prévu d'arrêter son développement. Pour information, la branche 2.x est la branche principale (trunk), contrairement à la branche 3.x qui est à part (branches/py3k).
Cela veut aussi dire que la référence c'est l'implémentation de guido et que personne d'autre ne peut être sur de correspondre à la spec
Sais-tu qu'il existe d'autres implémentations de Python que CPython (l'implémentation de référence écrite en C) ? IronPython (.NET), Jython (Java), PyPy (Python), ... Il existe une ÉNORME suite de tests pour vérifier la compatibilité (Lib/test/*py : ~430 fichiers contenant chacun plusieurs dizaines de tests). On s'en sert pour mesurer le niveau de compatibilité avec CPython : PyPy est proche du 100% (genre 99% je crois) alors que PyPy a été réécrit depuis zéro.
Si on prend plus précisément l'exemple des versions 2.x et les sections "Porting to Python 2.x" : (...)
Je connais mal ces documents, mais c'est souvent des corrections de bug (disons des comportements qui n'étaient pas prévus). On peut voir ça comme une rupture de la compatibilité (et oui, c'est le cas). Mais c'est voulu pour augmenter la qualité des language (et des logiciels écrit en Python). Un langage trop laxiste (allez, disons PHP) est source de problèmes difficiles à corriger et comportements inattendus.
Les changements sont quand même mineurs et rapides à corriger. D'ailleurs, c'est des cas particuliers qui impactent peu de projets.
J'ai écrit du code pour Python 2.4 (projet de +25.000 lignes) : il fonctionne sur Python 2.5 et 2.6 sans que j'ai eu à le modifier.
Bon, je peux me tromper, j'ai peu d'expérience dans la migration d'un gros projet 2.n => 2.(n+1). Je sais que Zope est bloqué en Python 2.4 par exemple. Il me semble qu'il y a un projet de migration vers 2.5 (alors que la dernière version stable de Python est la 2.6 :-/).