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 ;-)
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 (...)
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.
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 :-)
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
Python conserve les 100 dernières regex compilées, mais j'aurai tendance à penser qu'il vaut stocker les versions compilées pour des performances optimales. En Python, l'API sans compilation ou après compilation est identique (ou dumoins se devine facilement : on zappe le 1er argument) :
- m=re.match("regex", "texte")
- x=re.compile("regex"); m=x.match("texte")
Si Perl et ses contextes mystiques (opérations magiques selon le contexte) te plaisent, tu risques de pas aimer. Mais je pense que pas mal d'aspects de Python devrait t'intéresser. Python est fortement inspiré de Java, mais est beaucoup plus laxiste et concis (« moins verbeux »).
La méthode .sub() (« replace all ») accepter une chaîne ou une fonction pour le remplacement. Exemple : re.sub("([0-9a-f]+)", lambda regs: str(int(regs.group(1), 16)), texte, re.IGNORECASE) convertit les nombres hexadécimaux en décimal ("x=10" donne "x=16"). On peut extraire la lambda fonction (et la définir avant) pour une meilleure lisibilité.
Pour les traitements sur les ensembles (et non pas uniquement sur les tables de hash ou listes), Python implémente les itérateurs de manière très générique : « for x in data: ... » équivaut à :gen = iter(data)
while True:
x = gen.next()
...
Les types de base (dict, list, tuple) implémentent cette API. Mais de nombreux objets l'implémentent également : fichier (lecture ligne par ligne), résultat d'une base de donnée, document XML, etc.
À partir de ça, on peut créer des expressions de type : « results = [(x * 10) for x in data if (x % 3) == 2] ». C'est la forme abrégée deresults = filter(lambda x: (x % 3) == 2, donnees)
results = map(lambda x: x*10, donnees) ou encore results = []
for x in donnees:
if (x % 3) == 2:
results.append(x * 10)
Je trouve cette programmation, inspirée des langages fonctionnels, élégante. Bien qu'utilisé abusivement, elle peut rendre le code difficile à relire.
Je ne connais pas bien Perl, mais je pense que « @liste = %h{@t}; » s'écrit « liste = [h[cle] for cle in t] » en Python. C'est plus verbeux, mais se comprend plus facilement (pas besoin de connaître le sens des préfixes @ et $).
Au sujet des appels de fonction. En PHP, les objets passés en paramètres sont passés par copie. C'est assez pénible, il faut écrire explicitement &$object pour le passer par référence. Ceci peut être fait dans le prototype de la fonction... ou lorsqu'on l'appelle. S'en suit un gros merdier au niveau des effets de bord. En Python, tous les objets sont passés par références (et tout est objet), sauf que certains objets sont immutables (non modifiables) comme les tuples, les nombres entiers et les chaînes de caractères.
Pour l'assignation, pareil : c'est une copie de référence et non pas copie de l'objet : a=b fait que a et b pointent sur la même donnée. Par contre, lorsqu'on modifie a, b va être modifié ou non selon la même règle qu'avant :
- type mutable : a et b sont modifiés
- type immutable : a forke et crée un nouvel objet
En gros, Python est un pot pourri de divers langages (un peu de Perl par ci, un peu de Lisp par là, un peu de Java, etc.) mais qui en a extrait le meilleur pour donner un langage homogène et très souple.
Une raison particulière pour laquelle tu es passé par une variable temporaire ?
Oui, j'appelle ça la lisibilité :-) Je n'aime pas le code « malin » (que j'appellerai plutôt « concis » en réalité) qui au final n'est compréhensible que par son auteur. Mais oui, en Python on peut écrire des trucs sales !ident, value = re.match(r"(\w+)=(\d+)", line).groups()
(cette version stocke value sous forme d'une chaîne de caractères et non pas d'entier)
Note : il existe aussi les groupes nommés :>>> re.match(r"(?P\w+)=(?P\d+)", "cle=42").groupdict()
{'ident': 'cle', 'value': '42'}
J'avais testé Ubuntu Gutsy avec chiffrement de toutes les partitions y compris le swap. Et bien, le portable était beaucoup plus lent qu'avant (installation sans aucun chiffrement). Surtout qu'il n'a que 512 Mo de mémoire, alors ça swappe rapidement... C'était les options par défaut dans l'installeur, je me souviens plus des algos utilisés et si c'était le disque ou le système de fichier qui était chiffré.
à quoi est due la limitation sur le nombre de processeurs supportés ?
Je pense que quelqu'un qui choisit d'acheter Red Hat est intéressé avant tout par le support. Je comprend que jusqu'à 126 processeurs, Red Hat prend en charge tous les problèmes. Au delà, le support peut répondre « on sait pas faire » (mais ils vont sûrement tenter d'aider au mieux).
Côté noyau, la limitation est 4096 processeurs et 512 nœuds depuis Linux 2.6.27 (elle était de 255 processeurs et 32768 nœuds avant). Il y a de gros progrès dans le noyau quant aux performances avec beaucoup de cœurs/processeurs.
# Autre annonce EVE Online
Posté par Victor STINNER (site web personnel) . En réponse au journal CCP abandonne EVE Online pour Linux. Évalué à 2.
http://www.python.org/news/index.html#Mon09Feb20091000-0500
http://en.wikipedia.org/wiki/Eve_online#Demographics
[^] # Re: Hum Hum
Posté par Victor STINNER (site web personnel) . En réponse au journal Un ver s'attaque à la Marine française. Évalué à 5.
Je suppose que ce n'était pas le cas dans la Marine française.
[^] # Re: Outch ! Mon disque est affecté
Posté par Victor STINNER (site web personnel) . En réponse au journal Seagate / Maxtor, fabricant de briques. Évalué à 9.
- 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 !
# Outch ! Mon disque est affecté
Posté par Victor STINNER (site web personnel) . En réponse au journal Seagate / Maxtor, fabricant de briques. Évalué à 3.
...=== 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
[^] # Re: Quelques critiques d'un débutant
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 3.
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 ;-)
$ pythonPython 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 ;-)
[^] # Re: Bravo !
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 3.
[^] # 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 :-/).
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 3.
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.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 4.
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.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
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 ;-)
# Contre-pub à Microsoft Office
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Poster de promotion pour OpenOffice.org. Évalué à 4.
http://home.regit.org/?p=161
http://home.regit.org/?p=196
http://home.regit.org/?p=213
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
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.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
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.
[^] # Re: Critique
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 4.
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.
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
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.
[^] # Re: Merci pour l'information
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 5.
[^] # Re: J'hésite...
Posté par Victor STINNER (site web personnel) . En réponse au journal Explorez les richesses du langage Python. Évalué à 2.
[^] # Re: Orange et SFR?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche L'IPv6 débarque chez FDN. Évalué à 2.
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
[^] # Re: Orange et SFR?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche L'IPv6 débarque chez FDN. Évalué à 2.
[^] # Re: toujours sur les regexps
Posté par Victor STINNER (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
- m=re.match("regex", "texte")
- x=re.compile("regex"); m=x.match("texte")
[^] # Re: à propos des regexp...
Posté par Victor STINNER (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
# Python c'est super !
Posté par Victor STINNER (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 6.
Pour les expressions régulières : tout est objet en Python, donc une expression régulière est un objet et un « match » est aussi un objet. Voir la doc :
http://docs.python.org/library/re.html#regular-expression-ob(...)
La méthode .sub() (« replace all ») accepter une chaîne ou une fonction pour le remplacement. Exemple : re.sub("([0-9a-f]+)", lambda regs: str(int(regs.group(1), 16)), texte, re.IGNORECASE) convertit les nombres hexadécimaux en décimal ("x=10" donne "x=16"). On peut extraire la lambda fonction (et la définir avant) pour une meilleure lisibilité.
Pour les traitements sur les ensembles (et non pas uniquement sur les tables de hash ou listes), Python implémente les itérateurs de manière très générique : « for x in data: ... » équivaut à :
gen = iter(data)while True:
x = gen.next()
...
Les types de base (dict, list, tuple) implémentent cette API. Mais de nombreux objets l'implémentent également : fichier (lecture ligne par ligne), résultat d'une base de donnée, document XML, etc.
À partir de ça, on peut créer des expressions de type : « results = [(x * 10) for x in data if (x % 3) == 2] ». C'est la forme abrégée de
results = filter(lambda x: (x % 3) == 2, donnees)ou encoreresults = map(lambda x: x*10, donnees)
results = []for x in donnees:
if (x % 3) == 2:
results.append(x * 10)
Je trouve cette programmation, inspirée des langages fonctionnels, élégante. Bien qu'utilisé abusivement, elle peut rendre le code difficile à relire.
Je ne connais pas bien Perl, mais je pense que « @liste = %h{@t}; » s'écrit « liste = [h[cle] for cle in t] » en Python. C'est plus verbeux, mais se comprend plus facilement (pas besoin de connaître le sens des préfixes @ et $).
Au sujet des appels de fonction. En PHP, les objets passés en paramètres sont passés par copie. C'est assez pénible, il faut écrire explicitement &$object pour le passer par référence. Ceci peut être fait dans le prototype de la fonction... ou lorsqu'on l'appelle. S'en suit un gros merdier au niveau des effets de bord. En Python, tous les objets sont passés par références (et tout est objet), sauf que certains objets sont immutables (non modifiables) comme les tuples, les nombres entiers et les chaînes de caractères.
Pour l'assignation, pareil : c'est une copie de référence et non pas copie de l'objet : a=b fait que a et b pointent sur la même donnée. Par contre, lorsqu'on modifie a, b va être modifié ou non selon la même règle qu'avant :
- type mutable : a et b sont modifiés
- type immutable : a forke et crée un nouvel objet
En gros, Python est un pot pourri de divers langages (un peu de Perl par ci, un peu de Lisp par là, un peu de Java, etc.) mais qui en a extrait le meilleur pour donner un langage homogène et très souple.
[^] # Re: T'as tout compris
Posté par Victor STINNER (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
Oui, j'appelle ça la lisibilité :-) Je n'aime pas le code « malin » (que j'appellerai plutôt « concis » en réalité) qui au final n'est compréhensible que par son auteur. Mais oui, en Python on peut écrire des trucs sales !
ident, value = re.match(r"(\w+)=(\d+)", line).groups()(cette version stocke value sous forme d'une chaîne de caractères et non pas d'entier)
Note : il existe aussi les groupes nommés :
>>> re.match(r"(?P\w+)=(?P\d+)", "cle=42").groupdict(){'ident': 'cle', 'value': '42'}
# Chiffrement intégral du disque dur
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 5.3. Évalué à 0.
[^] # Re: Nombre de processeurs supportés
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Red Hat Enterprise Linux 5.3. Évalué à 4.
Je pense que quelqu'un qui choisit d'acheter Red Hat est intéressé avant tout par le support. Je comprend que jusqu'à 126 processeurs, Red Hat prend en charge tous les problèmes. Au delà, le support peut répondre « on sait pas faire » (mais ils vont sûrement tenter d'aider au mieux).
Côté noyau, la limitation est 4096 processeurs et 512 nœuds depuis Linux 2.6.27 (elle était de 255 processeurs et 32768 nœuds avant). Il y a de gros progrès dans le noyau quant aux performances avec beaucoup de cœurs/processeurs.