Discussion :

[michel92140]

Nim c'est Python en mieux et compilé, donc très rapide...

alors qu'un programme tournant sur windows/pc est transportable , avec (quasiment ) aucune modification
la compilation =créer un langage machine

[wiztricks]

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

[TJ1985]

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...

[sancelot]

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.

@gallima ce n est pas une incompatibilité mais plutot une évolution. toutes les chaines de caractère sont désormais unicode.


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....

[michel92140]

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 ?

[Bktero]

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 ?

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

[Sve@r]

jusqu'à ce que des innovations vraiment utiles m incitent à changer,

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.

J aime bien la simplicité de python2.7

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...

en plus j ai constaté qu'un programme que j'ai écrit en python 3 semblait nettement plus lent.
Peut être une fausse impression ?

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...