flan a écrit 1848 commentaires

oui, ton exemple est un exemple de mauvais code Python. Mais comme déjà dit, on peut faire des trucs sales dans tous les langages, y compris en C.

Mais voilà deux autres exemples de code

current_line = file_descriptor.readline()
current_line = int(current_line) # on sait que le fichier contient que des entiers

=> bouh, c'est sale, on change le type de current_line (de str à int).

int i;
for(i = 0; i < 10; i++) { blablabla }
[...]
i = mon_appel_de_fonction();
i += 42;
return i;

=> ouf, c'est bon, i reste un entier. Pourtant, je trouve que c'est bien pire que l'exemple précédent, vu que la sémantique de i a complètement changé entre les deux utilisations.

Alors, oui, l'inférence de type est plus propre, mais par définition c'est plus contraignant et ne permet pas la souplesse offerte par Python (genre la construction dynamique des types, la récupération des arguments dans un dictionnaire, etc.).

Bien sûr que le duck-typing a un certain nombre d'inconvénients (dont l'absence d'info dans l'IDE fait partie), mais également un certain nombre d'avantages également. Malheureusement, on ne peut pas tous les avantages en même temps, donc il faut faire un choix, et heureusement que tout le monde n'a pas fait le même :)

Au moins, l'approche proposée par Python 3 permet de supprimer à la demande certains des inconvénients. Dans 99% des cas, typer statiquement n'est pas gênant, mais parfois c'est vraiment pas pratique de devoir typer fortement (ou alors on type en « object », ce qui revient à ne pas typer), ou alors on peut construire sa classe peu à peu, remplacer dynamiquement certaines méthodes, etc. J'aime bien la possibilité de mixer les méthodes de programmation, ça permet parfois de bien se faciliter la tâche.

J'essaie déjà d'en faire, mais ce n'est pas toujours évident quand c'est une application graphique :(

Je suis d'accord avec toi.

Simplement, en général, quand je code un algo un peu compliqué, je code par petits bouts, en exécutant les fonctions avec du print un peu partout pour voir si j'ai le résultat attendu à chaque étape.
Au final, je n'ai pas l'impression de perdre tant de temps que ça…

J'ai du mal à utiliser des debuggueur, mais c'est vrai que dans 99% des cas, la stacktrace (quand je fais du Python ou du Java) me suffisent largement.

En revanche, quand je fais du C, j'ai dû ressortir gdb de temps en temps. Et toujours en C, je passe régulièrement un coup de valgrind pour vérifier qu'il n'y a rien de perdu.

« Window$ » … je n'avais pas vu cette écriture depuis bien longtemps. J'imagine qu'on a aussi le droit à iTune$, Googl€, et R€d Hat ?

Quant au /etc dans « Window$ », c'est sûrement parce que Windows est compatible POSIX.

Au passage, je ne vois pas ce que ma réponse a de plus évident.

Cela fait pourtant quelques années qu'Eclipse est en place. Changer d'IDE tous les 15 ou 20 ans, ça reste raisonnable, je trouve.

Je ne suis pas d'accord.

Ce n'est pas parce que tu peux écrire directement dans la mémoire d'une autre machine que c'est le même noyau. Il y a le Firewire qui permet ça (mais je ne pense pas que ça soit le protocole utilisé ;)), et d'autres protocoles réseau, genre Myrinet et Infiniband.

Plus exactement, OS X (il paraît qu'il ne faut plus dire Mac OS X) EST un UNIX (certifié, et tout, et tout).

Après, si on va chercher dans ses racines, il est en effet basé sur un userland BSD (avec un noyau « maison » Mach — NeXT racheté par Apple).

Exemple de base :

  from package.subpackage.module import maclasse
  def toto(arg1: maclasse, arg2: int) -> str:
     return ''     

Je teste actuellement (depuis ce matin, c'est dire si je maîtrise le sujet) PyCharm (version Python d'IntelliJ / PHPStorm).

Python 3 permet d'annoter le code en marquant les types d'entrée et de retour des fonctions ou méthodes, et j'ai découvert avec joie que pris en compte par PyCharm. Autrement dit, ça permet une complétion du code bien plus efficace. Spyder fait-il de même ?

Tout cela est à peu près disponible dans VIM (au moins en Python, je connais moins pour les autres langages), pas forcément besoin d'un IDE complet. Après, ça demande un peu de temps pour se faire sa configuration. Ceci dit, cela fait longtemps que je me dis qu'il faudrait que j'apprenne à utiliser un IDE pour le Python (notamment PyCharm), mais je n'ai jamais le courage de réapprendre tous mes réflexes (surtout qu'il faudra de toute façon que je conserve VIM à côté).

Mais je suis surtout d'accord avec ta dernière phrase. C'est d'ailleurs pour ça que j'aimerais pouvoir typer statiquement le Python (quitte à avoir un type optionnel), pas forcément pour les perfs mais plutôt pour les possibilités que ça apporte au niveau gestion des erreurs, debug et refactoring, …

Je vois un certain nombre d'intérêts à cette approche :

• facilité pour installer des paquets non fournis par la distrib sur une machine déconnectée d'internet
• possibilité d'installer des paquets sans être root (ce que ne permet pas aptitude) et sans avoir à recompiler
• impossible de casser le système en jouant avec les dépendances (genre j'aimerais un paquet qui veut une version un peu récente d'une lib utilisée par le reste du système),
• on garde la possibilité de les installer de façon automatisée (donc gestion de parc facilitée)

Nous sommes d'accord, il y a un certain nombre de manques, mais beaucoup ont été comblés sur les dernières versions 1.4 et 1.5.

Quant à la dépendance à Django… bof, je ne suis pas convaincu.

Oui, il faut installer une dépendance à django quand on veut utiliser « django-orm ». Mais je ne vois pas le problème, à vrai dire.
Que tu installes « django-orm » ou « django-full », dans les deux cas, tu as une seule et unique dépendance. Effectivement, si tu utilises uniquement l'ORM, tu as quelques fichiers qui ne serviront jamais à rien, et qui doivent bien prendre 0,01% de l'espace sur un serveur de base.

Ce n'est pas comme pyqt qui ramène un certain nombre d'autres dépendances (et binaires qui plus est, donc moins évidentes à distribuer).

quels sont les problèmes avec wsgi et l'ORM, exactement ?

Pour info, construire un paquet en Python est assez simple, quand on a un fichier setup.py déjà existant.

Il faut utiliser (python-distribute) et la commande supplémentaire bdist_stdeb.

Après, python setup.py permet de construire en ligne de commande des paquets .deb, .rpm, .tar.gz (binaire ou source), .exe, …

Accessoirement, on peut faire les choses encore plus proprement, avec un fichier setup.py bien construit, et en renommant (et modifiant un peu) le manage.py en monprojet-admin.

Le setup.py permettra d'installer le site web (qui est en fait un — ou plusieurs — module Python) comme n'importe quel autre module Python, et monprojet-admin sera installé parmi les autres binaires, donc dans /usr/bin ou /usr/local/bin.
Il faut simplement modifier le manage.py pour changer le env.setdefault('DJANGO_SETTINGS', 'monprojet.settings') en env['DJANGO_SETTINGS'] = 'monprojet.settings'

On aura donc un exécutable accessible depuis n'importe quel dossier permettant d'appeler les différentes commandes, y compris les commandes définies dans monprojet/manage/commands ( cf. https://docs.djangoproject.com/en/1.5/howto/custom-management-commands/ )

Et encore, il y en a en trop…

Le Launchpad (en gros, une grille présentant les applications installées, un peu comme sur Gnome3), par exemple : pour supprimer une application, il faut cliquer longtemps sur l'élément, pour que les éléments gigotent et qu'apparaisse alors une croix de suppression sur laquelle on clique.

Ce comportement est très pratique en tactile, mais inutilisable sur un ordi avec clavier et souris : permettre un raccourci clavier ainsi qu'un clic secondaire avec l'option de suppression aurait été beaucoup plus ergonomique.

…à vouloir un Python avec typage statique.

Peut-être peut-on faire une surcouche à la machine virtuelle, pour faire de l'inférence de type à la OCaml.

Peut-être cela pourrait-il t'intéresser : http://www.mypy-lang.org

Ce qui serait pertinent, c'est de comparer avec le C++, mais à la fois les performances et le temps de développement.

En général, quand on code en Python, c'est que soit les perfs ne sont pas importantes, soit on n'a pas le temps de faire une vraie version optimisée aux petits oignons avec du C/C++.

On m'avait expliqué (comprendre : je ne garantis pas l'explication) que ce genre de panneaux permettait d'avoir une base si on te surprend en train de faire des photos un peu gênantes. En gros, faire une photo de tourisme : tout le monde s'en moque et on ne prend pas la peine d'aller plus loin.
Par contre, si on te surprend en train de faire beaucoup trop de photos pour que ça soit honnête (en notant les heures de relève, les passages réguliers, … bref, comme dans les films), on a directement une justification légale pour fouiller un peu plus.

Simplement, écrire dans un texte de loi quelles sont les photos innocentes (ou pas), ce n'est pas facile. Alors, on interdit tout, et on tolère quand c'est manifestement innocent. Perso, ça ne me choque pas plus que ça dans la mesure où ces installations ne sont pas si courantes que ça.

Je connais des spotters qui se sont fait prendre par les gendarmes en bout de piste à photographier des avions militaires. Ils ont vérifié qu'il n'y avait rien de gênant sur l'appareil photo et ils les ont laissés repartir tranquillement.

Je suis également surpris du manque de commentaires. Je n'en ai pas l'utilité pour l'instant, mais bossant pas mal avec Python sur différents projets, c'est une des options que je garde en tête (avec numpy et cython) en cas de vrai besoin de performances.

Oui, mais là, au niveau de l'interface utilisateur il n'y pas de différence (il entre son login et son mot de passe).

En revanche, avec d'autres types d'authentification, il n'y pas de mot de passe (par exemple avec Kerberos ou avec un certificat)

En effet, je faisais référence à la réponse de Zenitram, pas à la tienne, désolé :)

OpenCA a l'air un peu mort, contrairement à EJBCA (qui passe en v.5)