flan a écrit 1829 commentaires

Du coup, j'ai essayé Clementine.

Et bien, si je devais l'utiliser, il me manquerait cruellement pas mal de fonctions.

• ça fait uniquement la musique (iTunes s'occupe également des films et des séries TV, sans compter la gestion des iPad/iPhone/…)
• il y a uniquement du transfert de musique avec les iPhone / iPad, et uniquement via USB (la synchro sur iTunes se fait automatiquement par wifi quand je charge mon téléphone)
• je n'ai pas l'impression que ça fasse une synchro complète (i.e. je commence un fichier sur mon téléphone, je continue sur un ordi et je le finis sur un autre : à chaque fois la reprise se fait au bon endroit automatiquement)
• besoin d'avoir un compte pour synchroniser les podcasts (je préfère largement le faire sur mon réseau local, et sans compte)
• impossible de synchroniser partiellement les bibliothèques sur deux machines différentes (i.e. je veux que sur mon ordi portable il y ait la même playlist TOTO que sur mon fixe, mais seulement celle-là parce que je n'ai pas assez de place)
• pas de gestion d'airplay (pratique pour envoyer la musique vers des périphériques dans d'autres pièces)
• pas de télécommande via téléphone

Donc peut-être qu'ils ont plein de fonctions absentes sur iTunes, mais ils ne font pas pour autant tout ce que fait iTunes…

Avec iTunes, dont la bibliothèque est stockée sur un partage AFP avec du RAID5 pour un minimum de sécurité. Au final, ça répond parfaitement à mes besoins, donc je le conserve.

Les iPhone et iPad prennent trop d'importance, apparemment :(

Tu compares l'incomparable. Développer du libre ne coûte pas plus cher que développer du proprio : c'est un fait.

*Ça ne coûte pas plus cher pour le développeur. *
Par contre, pour le client, c'est autre chose : la boîte ne pourra pas revendre le même développement à un autre client, donc ça lui fait un manque à gagner, donc on peut imaginer qu'elle aura tendance à facturer plus cher (pas très fair-play, mais je vois mal les SSII faire des cadeaux à l'administration).

Il se trouve que j'ai dû faire un certain nombre de petits sites web (appli web au boulot, petits trucs perso, …), et même si je n'aime pas spécialement ça, je commence à avoir une certaine expérience (pour un gars dont ce n'est pas le boulot).

Ça fait longtemps que j'ai opté pour du Python + Django, avec des pages relativement statiques (essentiellement parce que je n'aime pas le JS), avec une API REST fournie par Tastypie. Du coup, mes appels JS sont assez limités, et utilisent pas mal JQuery.

Par expérience, il est important de choisir rapidement le type de navigation :
- est-ce que la même URL doit servir pour les petits et grands écrans ?
- navigation possible sans JS ?
- possibilité de partager un lien vers une page quelconque du site ?
Transformer un site existant est en général coûteux en temps quand on n'est pas un pro, donc il vaut mieux partir sur des bases saines à ce niveau là.

Pour la sécurité, c'est un des intérêt d'utiliser un framework comme Django (ou autre) : il y a pas mal de protections de façon native, sans avoir de question à se poser (authentification, mais aussi protection contre les requêtes inter-domaines, etc.)

Nokia n'est pas passé à Windows Mobile, mais à Windows Phone. La différence semble être de taille à l'usage.

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