Salut,
Envoyé par
TiranusKBX
Pour les problèmes de migration je me suis retrouvé avec un truc plutôt con
entre le passage de la 3.4 et la 3.5 il y a eus une modification de la lib asyncio associé et je me suis retrouvé avec plusieurs fonction et variables d'asyncio don le nom change(exemple async vs ensure_future
), m'obligeant à tester si l'ancien nom existe toujours et sinon j'utilise l'ancien vus que je fait tourner ça sur des linux qui n'on par forcément la même version de python3
Je parie que ça vas faire de même avec la 3.6
Hum... Pas facile de louper cette mention explicite:
Note
The asyncio package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the module) may occur if deemed necessary by the core developers.
dans la
documentation du module.
Python 3.5 finalise le travail de fond commencé en 3.0 côté packaging avec "pip", le format "wheel", "importlib",...
Cela ouvre des opportunités de changements:
- le packaging de Qt séparant développement et run-time n'est pas une mauvaise idée. Elle aurait pu être prise plus tôt. PyQt5.6 annonçait déjà la couleur.
- cx_freeze: c'est un projet open source avec peu de développeurs qui ont aussi une autre vie. Ca fait des retards lorsque recompiler ne suffit pas, des utilisateurs qui râlent et d'autres développeurs qui
"forkent".
Ceci dit, ces améliorations ont pour vocation (dans un futur lointain) de ne plus avoir à compter sur
Gohlke pour avoir des packages prêt à l'emploi sur Windows, réduire la prolifération de tout-en-un comme PythonXY, Anaconda,... (ils existent surtout parce qu'installer c'est compliqué), faciliter un packaging multi-versions,...
Et ce que çà va trop vite?
Qt, PyQt, cx_freeze, Python,.... c'est autant d'équipes de développeurs qui ont leurs propres calendriers. Ils ne se concertent pas pour les changements et parfois ils s'accumulent... Ce qui peut être fort énervant.
Ceci dit, impossible d'être "à jour" dans les versions de tous les produits qu'on utilise, il faut travailler par plateforme i.e. des environnements stables construits avec un mix produits/versions mis à jour tous les ans ou tous les 2 ans (sauf gros bug..) Et on ne fait évoluer ses applications que lors de l'ajout de nouvelles fonctionnalités significatives.
note: çà ne veut pas dire qu'il ne faut pas explorer les nouveautés pour sa culture, pour savoir ce qu'on va figer plus tard, mais on peut essayer d'éviter que les applications qu'on développe ou que l'on maintient en dépendent trop tôt, trop vite.
J'ai aussi noté une baisse de la fréquentation du forum. Mais elle est aussi corrélée à une baisse de fréquentation de développez en général (il y a beaucoup plus de concurrents aujourd'hui qu'il y a 10 ans). Nous avons aussi une crise économique qui fait qu'on développe moins, qu'on privilégie plutôt tablettes et l'embarqué.
- W
1 |
0 |