Bonjour,
@gallima,
De quelle incompatibilité parles-tu ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Bonjour,
@gallima,
De quelle incompatibilité parles-tu ?
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
L'incompatibilité la plus importante à mon sens est celle de la représentation des chaînes de caractères. Passer d'une vision orientée 'byte' à une version orientée 'caractère unicode' a cassé tous les programmes qui utilisait les 'string' pour passer de la data raw. Par exemple, il n'est plus possible de mapper directement un 'char*' C vers python (enfin y a une méthode mais ce n'est pas directe). Le changement est si important qu'il est souvent plus simple de réécrire le code totalement. Y a d'autres incompatibilités qui existe, mais j'ai pu la liste en tête, celle-là a été suffisante pour moi.Envoyé par fred1599
Edit:
http://www.python-simple.com/python-langage/python3.php
Le coup du changement de comportement de la division peut aussi rendre des portions de code fausse et ce silencieusement...
je suis passé rapidement a python3.x... mais jusqu'a aujourd'hui ce langage m'a toujours gonflé a cause de existence de ces 2 versions :
Distrib linux qui utilise python2 par défaut (j'ai eu beaucoup de difficulté parfois avec des clients ou j'ai du réécrire mon code en python2 parce qu’ils ne pouvaient pas installer python3)
Documentation sur le net ou faut faire attention a chaque fois que c'est bien du python3 (heureusement c'est de moins en moins le cas avec les années)
Des libs qui n'existe plus ou alors des imports a modifier
...
Don la fin du support de python2.7, cela veux dire que les distrib linux vont devoir migrer 100% de leurs scripts et ne plus installer par défaut python2, je suis content... j'aurais aimer que cette fin de support arrive plus tot (disons en 2015)
bon débarra python2, repose en paix... vers silverlight
ça c'est encore une bonne excuse pour ne pas migrer : "il n'y a pas 100% des trucs que je veux dans python 3 (mais qui de toute façon n'était pas là dans python 2) donc je migre pas".
je suis d'accord avec calvaire, python 2 aurait du être mis de coté il y a au moins 10 ans. les gens/entreprises/etc trouveront toujours une bonne excuse pour pas le faire, ils n'ont toujours pas compris les risques à s'y prendre trop tard, qu'ils assument au bout d'un moment.
ps: en relisant c'est encore pire que ce que je pensais :
"la représentation fondamentale des chaînes de caractères a changé pour le pire et non le meilleur ;" dans python 3 des données sont des collections d'octets et des chaînes de caractères sont des collections de ... caractères, en quoi c'est pire qu'avant où les données étaient des chaînes de caractères? et maintenant on a la prise en charge correcte d'unicode, enfin je ne suis plus obligé d'utiliser une verrue dans mon code pour accéder à des fichiers avec des caractères funkies.
"la gestion des paquets était et demeure un cauchemar en utilisant une combinaison d’environnements virtuels pip pour installer les dépendances spécifiques au projet ;" ça n'a donc pas changé, je vois pas pourquoi imputer ça à python 3 ...
"comparé à d’autres langages, Python 3 est toujours lent, car il ne valoriserait que la simplicité par convention ;" pareil, ça se plaint que python 3 a changé trop de trucs, mais là que ça n'a pas changé, ça se plaint pareil ..., en plus tu fais du python pour sa simplicité d'écriture avant tout (enfin je pense), ou alors la personne ne sait pas choisir un langage
"la bibliothèque asyncio permettant d’écrire du code concurrent en utilisant la syntaxe async/await aurait été ajoutée assez tardivement ;" et donc? c'est tardif donc on migre toujours pas?
"des indications de type ont été ajoutées au langage en s’appuyant uniquement sur des analyseurs statiques de type hinting au lieu de créer également des vérifications de type d’exécution dans le langage, ce qui aurait été beaucoup plus utile et cohérent, selon l’intervenant ;" toujours pareil, ça reste du python, tu peux pas reprocher à la fois de trop changer et de ne pas assez changer, sinon autant faire un nouveau langage, ça aurait râler pareil néanmoins.
"jusqu’à présent, il n’y a toujours pas de fonctions lambda anonymes multilignes." pareil que ma première version du post, "il n'y a pas 100% des trucs que je veux donc je migre pas"
bref, j'ai la flemme de trouver une conclusion à ce merdier...
Euh... Leur joie !
Il faut bien finir par passer à autre chose...
L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.
Salut,
Il n'y a rien à dire: c'est tout le sens d'un changement de version majeure.
Ce n'est pas spécifique à Python: tous les produits qui ont eu à subir des évolutions majeures ont eu leurs soucis de jeunesse (c'est pour çà que certains attendent une version n.1 voire n.2 si ce n'est plus avant de se jeter à l'eau), des utilisateurs ravis d'y trouver les fonctionnalités qu'ils attendaient, d'autres fâchés de rencontrer problèmes (même si plupart du temps, ils sont mentionnés dans le release notes) et toujours pas les fonctionnalités qu'ils attendaient eux.
La plupart des logiciels dont dépendent des applications plus ou moins critiques ont tous un support long, voire très long des anciennes versions qui se traduit par la publications de correctifs (au sens large) les premières années et la publication des seuls correctifs de sécurité (en deuxième temps).
C'est comme çà.
- W
Tant mieux, cette situation avec 2 versions existantes etait ridicule, et moi je l'aime bien python 3.7
Passez à Nim
Nim c'est Python en mieux et compilé, donc très rapide...
perso si je fais du python, c'est justement pour, entre autre, me passer d'une étape de compilation, si tu proposes toi d'en rajouter une ...
bref, je vois pas le rapport avec la choucroute.
dans 99% des cas osef de la rapidité
.... à croire que tout le monde ici travail sur des calculs intenses sur des datacenter ou bien dans de l'embarqué où le but est de faire tourner un jeu AAA sur 64mo de ram
Oui voilà, Nim est compilé, a un type system évolué avec de la metaprogrammation, transpile vers C/C++/JS, est peu connu et a peu de bibliothèques. Donc en fait Nim n'a à peu près rien à voir avec Python...
Sauf que pour faire du hpc sur une plate-forme type Azure ou Aws déployer un exe (NIM) ou toute la pile Python et ses lib panda numpy etc cela n'a rien de comparable.. Et si en plus c'est plus rapide à l'exécution...
Sauf qu'ici le sujet c'est la fin du support de Python 2.
Si tu veux faire un troll Python/Nim/Rust/Julia ouvre un topic dans une section adaptée.
J'ai découvert Python il y a deux ou trois ans et la première chose qui m'a énervé a été ces deux versions. Sur Mac ça a été une grosse galère, encore plus lorsqu'il fallait installer des moteurs d'IA en version 3.
A mon sens cette migration aurait dû être faite il y a longtemps, l'unicode étant devenu incontournable. Mais bon, je débarque et je connais la nostalgie des vieilles habitudes...
@gallima ce n est pas une incompatibilité mais plutot une évolution. toutes les chaines de caractère sont désormais unicode.L'incompatibilité la plus importante à mon sens est celle de la représentation des chaînes de caractères. Passer d'une vision orientée 'byte' à une version orientée 'caractère unicode' a cassé tous les programmes qui utilisait les 'string' pour passer de la data raw. Par exemple, il n'est plus possible de mapper directement un 'char*' C vers python (enfin y a une méthode mais ce n'est pas directe). Le changement est si important qu'il est souvent plus simple de réécrire le code totalement. Y a d'autres incompatibilités qui existe, mais j'ai pu la liste en tête, celle-là a été suffisante pour moi.
il y a un guide de migration assez simple pour l ensemble des opérations, et une compatibility backward pour assurer rapidement la portabilité. https://python-future.org/compatible_idioms.html et https://portingguide.readthedocs.io/en/latest/
La ou ca fait vraiment mal, c'est si on a fait des applis graphiques , par exemple avec WxPython, la c est mortel pour le portage car il faut en plus se faner le portage Wx....
je continuerai à utiliser python 2.7 car je le maîtrise bien
jusqu'à ce que des innovations vraiment utiles m incitent à changer, et ce n'est pas actuellement le cas.
J aime bien la simplicité de python2.7, en plus j ai constaté qu'un programme que j'ai écrit en python 3 semblait nettement plus lent.
Peut être une fausse impression ?
compilé = dépendant du processeur
alors qu'un programme tournant sur windows/pc est transportable , avec (quasiment ) aucune modification
la compilation =créer un langage machine
Pas du tout, il est juste "transportable" vers un autre ordinateur qui tourne la même version de Windows mais pas du tout vers un Linux ou vers OSX (ou une autre version de Windows suivant les DLL utilisées) et ce même si les processeurs sont tous compatibles X86 (et donc à instructions machine identiques).
- W
Ton profil dit que tu es enseignant. J'espère que n'apprends plus Python 2 à tes élèves, et que tu le gardes pour toi uniquement
Ou jusqu'à ce que les outils que tu tentes d'utiliser ne soient plus compatibles. Je pensais comme toi il y a seulement un an. Mais voilà, tout d'un coup tu installes un truc et l'interface Python qui va avec le truc ne fonctionne qu'en P3. Et etc etc. Finalement j'ai basculé. Je ne dis pas que ça a été évident mais bon, cela n'a pas été quand-même la difficulté ultime. Et quelque chose me dit que maintenant que P2 est arrêté, tu y viendras beaucoup plus vite que tu ne crois.
Euh... je trouve tout de même que P3 a simplifié pas mal de trucs. object hérité par défaut dans les classes, super() qui peut être maintenant appelé sans paramètre (crois-le ou pas, ça m'a sorti d'une difficulté basée sur une classe privée dont j'héritais et que je n'avais pas solutionné en P2), les viewxxx et iterxxx qui ont disparu des dictionnaires tous maintenant englobés dans xxx (key, values, items). Plus de séparation int/long et unifications des strings toutes unicode. Ca aussi ça m'a fait supprimer quelques lignes quand j'ai porté mes scripts...
Peut-être parce que ce genre de phrase un peu "dans le flou" ne veut rien dire. "un" programme. Comment as-tu fait tes benchmarks ? Il faisait quoi ce programme ? Il était alone ou utilisait des libs externes ? Il y a plein de circonstances qui font qu'un programme peut être plus lent...
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager