Victor STINNER a écrit 1639 commentaires

Il se passe quoi quand il te manque un module python pour lancer ton executable python ?

Si tu utilises la bibliothèque standard, tu es sûr que le module est disponible.

Pour les dépendances (modules tiers), c'est le même bazar qu'importe le langage. Pour Python, y'a la méthode setuptools, la méthode Debian, etc.

Est-ce que toutes les implémentations de python sont conformes ?

En gros, il y a CPython (l'implémentation de référence) et les autres :-) PyPy est compatible à 99% (allez, on va dire 100%), mais reste expérimental. Jython et IronPython implémentent un peu comme ça leur chante quitte à briser la compatibilité (je pense en particulier à IronPython qui fait n'importe quoi) :-/

Y'a t'il un truc strictement décrit qui permettrait de confirmer que la lib correspond à sa spé ou on part du postulat que c'est vrai ?

Pour mesurer le compatibilité, il y a l'énorme suite de tests sur la bibliothèque standard.

Pour information, de quand datent tes connaissances sur le C++ ?

Hum, ça doit faire 2/3 ans que j'ai plus touché au C++.

--

Au sujet de wxWidgets, extrait de la FAQ :
http://www.wxwidgets.org/docs/faqgen.htm#stl

« ... it is in wxWidgets' best interests to avoid use of templates. Not all compilers can handle templates adequately so it would dramatically reduce the number of compilers and platforms that could be supported. »

« The standard C++ string class is not used, again because it is not available to all compilers, and it is not necessarily a very efficient implementation. »

Le fichier README parle d'une version stable 1.0. Mince, je me suis fait avoir j'ai pris une version 0.6 qui doit sûrement être instable. Je vais pour charger la version git du coup : $ git co ssh://jbdenis.net:9999/belier
git: 'co' is not a git-command
$ git checkout ssh://jbdenis.net:9999/belier
fatal: Not a git repository
$ svn co ssh://jbdenis.net:9999/belier
svn: Schéma d'URL non reconnu pour 'ssh://jbdenis.net:9999/belier'
Bon, pas compris. Tiens, un fichier exécutable qui s'appelle bel, essayons ça :$ ./bel
SALUT
help
??
^D
Euh, qu'est-ce qui s'est passé ? Il n'y a pas d'invite, il ne me dit pas ce qu'il fait, j'ai rien compris. En lisant, les sources je découvre que « bel » (bel... belier ?) prend des arguments !$ ./bel --help
Usage: bel [options]

Options:
--version show program's version number and exit
-h, --help show this help message and exit
-e FICHIER, --entree=FICHIER
contient les ordres pour générer le ou les scripts
-s RÉPERTOIRE, --repertoire-sortie=RÉPERTOIRE
répertoire où entreposer les fichiers générés
-d DÉLAI, --delai=DÉLAI
en secondes pour exécuter une commande du script

$ ./bel --version
bel 0.1
Décidément, j'ai vraiment pas la bonne version :-)

Pourquoi le projet génère des scripts shell plutôt que des scripts Python ? Python est plus portable que shell (moins de conflits entre sh, bash, zsh, etc.) ;-)

Je cherchais la référence à Fusil dans le code source, mais je n'ai rien vu. Le site web parle de tests, je ne les vois pas non plus dans le tarball.

Bélier semble stocker les mots de passe en clair. C'est pas terrible. Si un pirate vole un fichier .sh, il connaît les nom des machines, les logins et mots de passe associés. Perso je bloque l'authentification par mot de passe et force l'authentification par certificat (fichiers ~/.ssh/id_rsa et ~/.ssh/id_rsa.pub). Ma clé SSH est protégée par une longue passphrase. Même si un pirate me vole la clé, il lui faudra la passphrase pour l'utiliser.

Oui, donc en gros, de ce que je lis, le plus gros bonus de Python est qu'il impose une bibliothèque "standard" alors qu'en C/C++, on te laisse le choix

Hum, quand je vois la batterie de tests lancés par les autotools pour tester si on a bien tout ce qu'il faut, je trouve Python beaucoup plus agréable. J'avais fait un peu de C++, et ce que j'en ai retenu : c'est qu'on ne peut pas supposer que la STL est complètement et correctement implémentée. Je me souviens de wxWindows (maintenat appelé wxWidgets) qui avait du mal à migrer à la STL (ex: utiliser std::string plutôt que leur classe maison) car ils visent une grande portabilité et la plupart des compilateurs n'étaient pas prêt. Résultat : chacun recode son std::string (ex: QString dans Qt) dans son coin... Et encore, j'ai pris l'exemple le plus trivial, la STL c'est un peu plus gros que juste les chaînes de caractères ;-)

Qui a dit que Python impose une bibliothèque standard ? Oui, elle est disponible à coup sûr, mais libre à toi de l'utiliser ou non ! Bien sûr, tu peux recoder ta propre bibliothèque standard à toi et réutiliser plein de bibliothèques non standards (ex: setuptools, twisted, PyQt, ...). Mais pour les tâches simples, on est très content d'avoir des bibliothèques fonctionnelles de base.

avahi demande que le port udp/5353 soit ouvert pour fonctionner.

J'ai appris récemment qu'avahi permet de contacter une machine dans le réseau local selon sous nom sous la forme « nom.local ». Exemple : « ping lisa.local » va résoudre le nom « lisa » avec avahi. Ça évite de mettre en place un serveur DNS ou de modifier /etc/hosts sur chaque machine (j'utilisais la 2e solution, avec 3 machines c'est supportable).

Choose unicode.

Choose Python3 (qui n'a plus ces problèmes d'Unicode).

Debian Sid était gelé (si si !) à cause de Lenny. Maintenant que Lenny est sorti, ça va décoincé Sid pour accueillir de nouvelles versions comme KDE4.

J'ai un ami qui utilise KDE4 et il me répète régulièrement que c'est instable et incomplet. Je préfère que Debian continue d'embarquer KDE3. KDE 4.2 est tout frais, Debian n'a pas eu le temps de packager le bousin.

J'ai retouché un peu la dépêche : gcc était présent deux fois, j'ai supprimé Emacs de la catégorie bureautique et j'ai simplifié un peu les versions. Pourtant afficher deux versions pour MySQL et Python ? Pour python par exemple, c'est 2.5.2 la version par défaut ? (quand on tape "python")

Je ne vois aucune référence au nouvel installeur graphique. Les notes de sortie de Lenny parlent aussi de Xfce, LXDE, FHS, LSB, OpenJDK (Python, Perl mais pas Java ? pourtant c'est "un peu" utilisé comme langage :-)), Asterix, etc.

Il manque pas mal d'infos très intéressantes de :
http://www.debian.net/News/2009/20090214

Il serait bon de rappeler brièvement ce qu'est le projet Debian, parler des variantes (ex: Ubuntu), et indiquer les différents moyens de télécharger (installer?) Lenny.

CCP Games announce that EVE Online recently achieved a new record number of players at 51,674, breaking the 50k barrier for the first time.
http://www.python.org/news/index.html#Mon09Feb20091000-0500
http://en.wikipedia.org/wiki/Eve_online#Demographics

Il me semblait que l'armée utilise deux physique réseaux séparés. Le réseau sécurité n'est utilisé qu'avec des machines qui n'ont aucun moyen d'injecter des données (pas de lecteur de carte / CD / DVD / USB / ...). Il faut toute une procédure pour rentrer ou sortir des données.

Je suppose que ce n'était pas le cas dans la Marine française.

J'ai fait la mise à jour. Quelques conseils avant de màj :
- Notez le modèle sur un post-it (il sera redemandé dans l'outil de màj)
- Notez la version du firmware (également donnée par smartctl)

Pour màj :
- l'image ISO gravée donne un CD bootable basé sur FreeDOS : on boote dessus, yahoo !
- pour taper la lettre A, il faut taper Q (clavier QWERTY...)
- la mise à jour est lente, soyez patient : ensuite l'outil va rebooter en éteingnant électriquement la carte mère. DON'T PANIC ! C'est normal si votre ordinateur s'éteint alors qu'il venait d'écrire des messages que vous n'avez pas eu le temps de lire :-p

Retour sous Linux : vous pouvez vous assurer que la version du firmware a changé (SD15 => SD1A dans mon cas).

PS : Même si vous n'avez pas de Seagate, ça mange pas de pain de faire une sauvegarde une fois par mois sur un disque externe (Seagate ou autre ;-)).

PS2 : Les màj de firmware me donnent toujours des sueurs froides. Mais il faut savoir vivre dangereusement !

Pour vérifier si votre disque est affecté, lisez le modèle et numéro de série avec le programme « smartctl -a /dev/sda » (remplacez /dev/sda par votre disque) :...
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.11
Device Model: ST3500320AS
Serial Number: 9QM6TW8B
...
Entrez le modèle, puis le numéro de série dans les outils en ligne Seagate (voir l'URL du journal). Perso j'ai eu du mal à ce putain de recaptcha ! Si les numéro correspondent, jackpot ! La 4e étape amène ici :
http://support.seagate.com/firmware/firmnav_en.html

Je n'ai plus fait de programmation depuis [20 ans] donc je me suis dis que cetait une occasion de m'y remettre: (...) j'étudie ce hors série surtout la partie science

Pour débuter dans Python, je doute que numpy et scipy soient les modules les plus simples à apprendre :-) Python est quand même une super calculette, qu'autant qu'il a des nombres entiers de taille illimitée (limitée par la mémoire) et des nombres complexes ;-)$ python
Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>> 1+1
2
Waouh ! Bon, voir le module math pour des trucs plus utiles ;-)

À vrai dire, je pense qu'il y a déjà suffisamment de ressources pour apprendre Python disponible gratuitement sur Internet. D'ailleurs, l'annexe de l'article « Apprenez d'abord Python » regorge de références !

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 :-/).

En gros tu dis que le langage reste compatible mais pas les bibliothèques..

Hum, ce n'est pas ce que je voulais dire : la compilation des bibliothèques (Python) écrites en C pose problème. L'API de ces bibliothèques est inchangée.

En conclusion, si vous bossez avec des gens payés au lance-pierre et qui n'ont pas la volonté du travail bien fait (ni le temps d'ailleur), ne faite pas de Python, c'est des ennuis assuré.

Un mauvais programmeur arrivera toujours à écrire du code horrible... qu'importe le langage. Des fois, c'est à se demander s'il ne se donne pas du mal pour que le code soit incompréhensible et très difficilement maintenable :-)

J'ai déjà vu une réimplémentation de strcpy() dans un programme C++ (ce n'était pas une fonction, le code était recopié). Ou encore un classe dont le constructeur prenait 30 arguments (nommées a, b, c, ..., z, aa, ab, ... bien sûr) en C++. C'était un projet professionnel bien sûr :-) Ce n'est pas parce que le langage offre de super outils (ex: template, itérateurs, etc.) qu'ils vont être utilisés. Le problème est une mauvaise connaissance du langage, un manque d'expérience (apprentissage sur le tas) et toujours le manque de temps.

Concernant le temps de compilation, bien sûr c'est long.Mais est-ce que c'est plus long que d'écrire un milliard de tests ou de planter après 2h d'éxécution pour pallier à l'absence de la phase de compilation (genre se tromper sur l'objet que tu passe à une méthode, détecter à 98% par le compilateur, jolie execption à l'éxecution sinon :))

C'est un faux problème. Effectivement, le compilateur C++/Java va refuser de compiler si on n'utilise pas les bons types. Par contre, les bugs « après 2h d'exécution » existent également en C++ et Java. Le compilateur n'est en rien une garantie que le programme ne va jamais planter. Les tests sont également nécessaires en C++ et Java pour garantir le bon fonctionnement du programme (on teste les cas qui marchent et on teste qu'une erreur est levée pour les cas invalides).

Je pense qu'un compilateur rassure les développeurs : si je me trompe, le compilateur va détecter mes erreurs. Or seuls un petit nombre d'erreurs sont détectées : les fuites de mémoire, lecture n'importe où en mémoire, faille de sécurité et autres ne sont pas détectées par le compilateur vu que les erreurs ne peuvent être détectées qu'à la compilation ou par une lecture attentive du code source.

L'absence de type est une force de Python : le duck typing permet d'écrire un algorithme générique à moindre frais : temps de compilation (en C++, il faut recompiler la fonction pour chaque combinaison de types) et code concis (pas besoin des horribles templates mégaverbeux de C++).

Note : pylint, pychecker et pyflakes comblent partiellement le manque de « compilateur » en Python (en réalité, Python est un compilateur : code source => bytecode Python). Python 3 autorise maintenant la déclaration des types mais ils ne sont pas validés, c'est juste informatif. Je pense qu'un drogué de C++/Java va écrire un outil pour valider les types ;-)

Ça pourrait donner des idées à certains :
http://home.regit.org/?p=161
http://home.regit.org/?p=196
http://home.regit.org/?p=213

Exemple n°3 : On parle par exemple de la simplicité du python et de pouvoir faire un for element in list (...) cette affirmation un peu fausse. J'utilise le toolkit Qt (...)

J'ai écrit un bref comparatif Python/C++ et Python/Java avec un exemple un peu plus élaboré que print "Hello" :
http://www.haypocalc.com/wiki/Python_ou_rien#Comparatif_avec(...)

Je rajouterai :
* C++ est trop long à compiler (la précompilation des entêtes aide un peu)
* C++ manque de modules standards, bien qu'il existe de grosses bibliothèques très utiles, portables et libres (ex: Qt, Boost)

Il y a aussi une différence importante sur la manière de concevoir les API. En C++ et Java, on adore mettre des const, static, private, etc. partout en obligeant l'utilisateur de l'API à passer par des méthodes. C'est utilisé pour qu'un utilisateur n'ait pas à se soucier de l'implémentation mais aussi pour éviter qu'il fasse n'importe quoi !

En Python, on a plus tendance à ne rien cacher et autoriser à tout modifier n'importe comment (cathédrale vs bazar ?). Bizzarement, ça marche : les projets Python restent lisibles et maintenables.

Python :print ''.join(sorted(open('/etc/passwd').readlines()))
C :
#include <unistd.h>
int main() { (void)execl("/usr/bin/sort", "/usr/bin/sort", "monfichier", NULL); return 1; }
Bien que le code C utilise le programme externe sort, il est quand même plus long :-) (deux fois plus de lignes !)

Et le mix ?
#include <unistd.h>
int main() { (void)execl("/usr/bin/python", "/usr/bin/python", "-c", "print ''.join(sorted(open('/etc/passwd').readlines()))", NULL); return 1; }
Bon ok, j'arrête.

Oups, j'ai oublié un détail (...) ,NULL

Bah tiens, une bonne raison d'utiliser Python : en Python pas besoin de mettre de bouchon pour indiquer qu'on a fini de lister les arguments. J'adore les fonctions qui acceptent un nombre illimité d'arguments « def f(*args): ... » ! De plus, le code bogué va provoquer un méchante erreur de segmentation alors que Python lève un exception qu'on peut attraper et traiter si on oublie un argument.

Il y a un autre problème qui est commun à python et java : ils ne sont pas standardisés (ISO ou autre). (...) ne sont pas stabilisés ce qui implique qu'il faut revoir sa copie fréquement.

De quoi tu parles ? Un code Python 2.0 (2000) fonctionne encore sur Python 2.6 (2008). D'ailleurs, je pense qu'on peut écrire du code qui fonctionne sur Python 1.5 (1999) et 3.0 (2009). Les changements qui brisent la compatibilité surviennent à tous les changements de version majeurs : 2.0 (2000) et 3.0 (2009), sachant que la branche 2.x est encore en développement en ne va pas s'arrêter avant quelques années.

En général, les nouveautés sont des ajouts et non des suppressions. Exemple : dans Python 2.6 on peut écrire 0o10 (8 en octal), avant on écrivait 010... mais l'ancienne syntaxe est encore autorisée. Donc l'ancien code continue de fonctionner.

Le vrai problème vient des modules Python écrit en C qu'il faut recompiler pour chaque nouvelle version de Python, et l'API change un peu à chaque fois. J'ai entendu pas mal de monde qui conservait une ancienne version de Python car un module précis ne fonctionnait pas sur la nouvelle version de Python. Solution : se passer de ces modules ou les réécrire en Python (ex: avec ctypes), mais j'avoue que cette solution n'est pas faisable pour de gros modules si on n'a que peu de temps devant nous.

Il me semble que Java fait également attention à la compatibilité ascendante.

Bizzarement, même pour des gens qui ont suivi une formation et on déjà un gros bagage technique en programmation, Python reste un langage apprécié et très agréable :-)

Je ne peux te garantir ça.

Utiliser MSN derrière du NAT, c'est un transfert de fichier bridé à 4 Ko/sec (la dernière fois que j'avais testé) car il utilise un proxy HTTP chez Microsoft. Il y a aussi les logiciels de P2P (BitTorrent, eMule, etc.) qui n'aiment pas le NAT.

Même en se passant complètement du NAT (on peut toujours rêver), ça ne va pas résoudre tous les problèmes. Certains protocoles réseaux échangent des adresses IP dans les couches OSI > 4 (ex: couche 7 pour FTP), ce qui emmerde beaucoup l'admin qui veut les filtrer proprement.
http://fr.wikipedia.org/wiki/Protocole_réseau_passant_difficilement_les_pare-feu