flan a écrit 1865 commentaires

J'ai tendance à être comme toi, mais parfois faire du typage dynamique (voire générer des classes à la volée) est parfois bien pratique. Ça permet (parfois) de beaucoup simplifier le code. Personnellement (mais je ne prétends pas que ça soit LA méthode à suivre), j'essaie de faire comme si Python avait un typage statique fort (90% du temps, à la louche), mais je n'hésite pas à faire du duck-typing et autres joyeusetés quand ça aide vraiment à avoir un code plus concis et plus lisible.

Pendant ma thèse, ceux qui tapaient leurs manuscrits sous Word s'arrachaient les cheveux à chaque modification pour cause de déplacement intempestif des images lors des ajouts/suppressions de paragraphes: toute la mise en page foutue en l'air.

Ça m'est pourtant souvent arrivé en LaTeX. Tu rajoutes une petite phrase (ou un mot), et ton document prend une page de plus… ou le contraire : tu rajoutes un mot, et ton article perd une page.

Pour mon boulot, je dois reprendre des documents tapés avec Word par d'anciens collègues. Entre ceux qui utilisaient MathType, ceux qui foutent des line break (shift+enter) parce qu'ils veulent sauter des lignes sans faire apparaître l'espacement inter-paragraphe (ce qui donne des situations cocasses en justifié), ceux qui changent le formatage des titres 1 par 1 sans définir correctement le style, je n'ai pas l'impression de gagner en productivité avec Word…

Tu compares du Word tapé par des personnes qui ne savent pas se servir de Word à du LaTeX tapé par quelqu'un qui sait se servir de LaTeX. La comparaison est subtilement biaisée, non ?

J'ai déjà généré via des scripts des documents pour Word : il suffit de générer du HTML, et Word saura parfaitement l'ouvrir et l'éditer (pour l'enregistrer dans du .docx).

D'ailleurs, j'ai eu à générer le même document pour Word (donc via HTML) et pour LaTeX : j'ai eu beaucoup plus de mal à avoir un rendu correct sur LaTeX, notamment pour les caractères spéciaux et pour une mise en forme automatique.

Pourquoi attendre un test alors qu'on peut avoir l'information dès qu'on écrit la ligne de code ?
Personnellement, ajouter l'info de type m'a permis plus d'une fois de corriger un bug avant même de faire le moindre test.
Ça ne remplace pas la doc, les deux informations sont complémentaires (d'autant que la documentation fait apparaître le type, et permet d'avoir un lien vers le type attendu).

Après, le système de types a deux intérêts (à mes yeux) : le premier est pour le programmeur vu que ça l'aide à ne pas faire d'erreurs, le second est pour le compilateur qui permet de faire un code bien plus optimisé.
Le second n'est pas trop utile pour Python même si c'est toujours bon à prendre : la vitesse n'est de toute façon pas le premier critère de choix quand on fait du Python.
Le premier peut être mis en place différemment, et peut n'être utilisé que dans l'IDE. Quand je code en Java/Scala ou en Python, la vérification des types se fait de toute façon avant la compilation (et je m'en moque un peu qu'ils soient écrits dans des commentaires ou dans le code). Par contre, ça impose d'utiliser un IDE correct (et tout le monde n'aime pas ça).

Il parle de l'obligation de filtrer pour distinguer les cas licites des cas invalides, pas pour différencier les différents cas valides (enfin, c'est ce que j'ai compris). L'idée est que si le cas est invalide, bah tant pis, le développeur n'avait qu'à mieux lire la doc :)

Python n'a pas que le typage dynamique comme avantage ;-) (syntaxe concise, écosystème très vaste, …) Accessoirement, j'utilise toujours le typage dynamique, mais uniquement quand j'en ai réellement besoin.
Par expérience, je gagne du temps en codant quelques lignes de plus grâce à l'aide supplémentaire offerte par les informations de type.

Personnellement, j'utilise PyCharm, qui tente de faire de l'inférence de type, et je l'aide en rajoutant les commentaires comme conseillés par Guido.
J'essaie de typer toutes mes variables et fonctions, ça me permet d'avoir d'avoir des alertes dans le code à peu près comme en Java ou dans n'importe quel autre langage typé statiquement. Je utilise le moins possible le typage dynamique.

Ça, c'est la théorie.

En pratique, ça ne marche pas bien.
J'ai une classe A définie dans un module a.py, et une classe B définie dans b.py.
Comment puis-je faire pour que A ait une méthode qui prenne un B en argument, et que B ait une méthode qui prenne un A en argument ?
(vu que ça nécessite que a.py import b.py, et que b.py importe a.py…)

De plus, c'est mal pratique pour définir des types un peu complexes (une liste avec différents types, un dictionnaire de dictionnaires de AxB, …)

Je ne vois pas trop ce que ça change : ça relancera peut-être le worker, mais il aura toujours des arguments incorrects donc ça ne fonctionnera pas plus (sauf que tu ne te rendras pas compte qu'il y a un bug, ce n'est pas vraiment sain comme méthode).

À ce propos : avec Linux, le chemin n'est qu'une suite d'octets. C'est à l'application de savoir quel est l'encodage utilisé, et tu peux tout à fait avoir dans le même dossier des fichiers avec différents encodages.
Avec OS X, le système de fichiers (ou le noyau ?) impose l'utilisation d'un encodage (et d'une normalisation Unicode) bien précis.
Je crois que Windows est comme Linux, mais s'attend à ce que ça soit de l'UTF-16 (sans normalisation précise).

Merci pour l'info, ça a l'air vraiment pas mal !
Je souffre à chaque fois que je dois faire du JS, et il y a des chances que je doive recoder une appli en Python + Qt (avec PySide) en JS…
Je me demande si je ne vais pas essayer avec Brython.

Ce qui te dérange, c'est surtout que des gens se sont mis ensemble et ont eu du succès.

C'est pratique, tu sais mieux que moi ce qui me dérange ou pas. Je me demande comment tu fais…

Au passage, non, ce sont les méthodes employées et les conditions de travail de leurs employés qui me dérange ; si les libraires s'unissent et qu'ils utilisent les mêmes méthodes, ça ne m'intéresse pas ; je pensais avoir été suffisamment clair en disant que les mauvaises conditions de travail me dérangent, mais manifestement non. Je ne comprends pas trop ce qu'il y a de compliqué là-dedans, pourtant.

Oui, en effet, j'ai mis UTF-8 au lieu d'Unicode, simplement parce que ça reste vrai : l'utilisateur tape un caractère « è », il est représenté dans le système de fichiers par de l'UTF-8 (ou de l'UTF-16/-32), même si la normalisation qui pose problème se fait au niveau de l'Unicode. Le conflit n'existe pas en Latin-1, parce qu'il n'y a qu'une seule façon de représenter le « è » (et qu'il n'y a pas d'histoire de normalisation NFKD/NFKC en amont).

De plus, tant qu'on parle d'Unicode, les deux versions (« è » et « e + ` ») doivent être comparées comme étant égales par le logiciel. Par contre, quand elles sont encodées (en UTF-8) et que ça devient des séries d'octets, les deux versions sont différentes (Linux ne considère que des séries d'octets, sans prendre en compte que c'est de l'Unicode) et à ce moment là, on a un souci (deux fichiers avec un nom identique).

Mais bon, c'est vrai que c'est totalement hors-sujet de parler UTF-8 au lieu d'Unicode, il n'y a strictement aucun lien entre les deux. Mea Culpa.

Personnellement, je connais des libraires, et leurs conditions de travail sont quand même bien meilleures que celles des employés de base d'Amazon (qui ne gagnent pas 100k$/an, mais bon, c'est tellement pertinent de se concentrer sur les quelques ingés en ignorant le reste des employés…).

C'est tout de même totalement idiot (ou de mauvaise foi, au choix) de dire qu'une boîte comme Amazon a les mêmes armes qu'un libraire classique :
* pas le même pouvoir de négociation avec les éditeurs (certains doivent vendre à perte à Amazon sous peine d'être exclus et donc de perdre toute visibilité),
* pas le même pouvoir de négociation avec les transporteurs (plus le volume est important, moins tu paies),
* pas le même pouvoir de négociation avec les États pour les impôts,
* pas le nombre d'avocats pour trouver la meilleure optimisation fiscale,
* pas le même pouvoir de négociation avec les États pour avoir des subventions quand ils s'installent quelque part,
* possibilité de pressurer les employés au maximum en les payant un minimum.

Plus il y aura de grosses boîtes comme Amazon, moins les conditions de travail (pour les employés de base) seront bonnes. Je ne pense pas que ça te dérange plus que ça, mais personnellement ça m'empêche de faire la moindre commande à Amazon ; je ne veux pas subventionner un système que je n'aime pas.

3/ les Américains n'étaient pas au courant de leur existence et ils les ont trouvées bien trop tard et par hasard vu que les preuves qu'ils ont présentées étaient bidon. Ce n'est pas la seule fois où ils ont données de fausses preuves : ils avaient déjà essayé de montrer sur des images satellites un mouvement de troupes irakiennes allant vers l'Arabie Saoudite (de mémoire), alors qu'elles allaient dans la direction opposée…
Ce n'est pas pour rien que la France a décidé en 1995 de se doter de satellites d'observation : c'est parce que les images américaines n'étaient pas fiables.

Ça ne m'étonne pas que Mercurial ait vu le souci : ils ont l'air de se poser beaucoup de questions sur le sujet, tout comme les problèmes de collisions avec les fichiers qui ont des noms UTF-8 : il faut savoir qu'en UTF-8, un même caractère peut être représenté de plusieurs façons (« è » peut être stocké comme un « è » ou comme un « e + ` »). Sur Linux, on aura donc plusieurs fichiers avec exactement le même nom (et de façon indiscernable pour l'application), alors que sur OS X le système de fichiers est normalisé (NFKD de mémoire) et il y aura un seul fichier (Windows est comme Linux, je crois).

Le typage dynamique est super pratique de temps en temps !
Mais 99% de mon code pourrait être typé statiquement sans problème. D'ailleurs, j'aimerais vraiment un Python typé statiquement par inférence de type.

À mon avis (basé sur assez peu de choses, je le reconnais), l'admin sys Linux moyen est nettement plus compétent que l'admin. sys Windows moyen, ne serait-ce que parce qu'il est beaucoup plus facile de s'improviser admin sys Windows (en cliquant suffisamment partout, on peut arriver à faire tomber en marche le système, sans comprendre ce qu'on a fait).

Je pense que tout le monde a connu des gens qui se sont improvisés experts Windows simplement en étant un peu moins mauvais que leur entourage.

Et entre les mains d'admin compétents et bien formés  ?

La seule chose à faire avec un mauvais admin, c'est de lui enlever les droits root en attendant qu'il soit bon ; il fera des catastrophes avec n'importe quel OS, GPO ou pas.

Parce que le HTTP permet beaucoup d'autres choses sans avoir à les recoder dans leur protocole maison, et ça va bien au-delà de binder des ports TCP sur 0.0.0.0 :

• nouvelles méthodes d'authentification (Apache ou Nginx permettent beaucoup de choses à ce niveau-là),
• utilisation de proxy (proxy directs ou reverse proxy),
• réutilisation de ports déjà ouverts sur les différents firewall,
• possibilité de faire du MITM pour la sécu…

mais je me demande toujours ce que ça donne en termes de perfs.

En effet, mais ça dépend de la méthode : faire du SSO avec kerberos est assez facile pour un client lourd, mais les méthodes genre Shibboleth sont nettement plus dures à passer (redirections multiples, utilisation de cookies, javascript, …).

La synchro HTTP est vraiment la bienvenue, ça aidera pas mal quand il est compliqué de faire ouvrir un port supplémentaire. En revanche, je me demande si la synchro HTTP est aussi performante que la version précédente.

Il manque encore l'authentification via HTTP (par exemple en se basant sur un header HTTP, au hasard REMOTE_USER). Ça permettrait d'avoir facilement pas mal de nouvelles méthodes d'authentification comme Kerberos.

Et parce que le port de nginx ne sera pas ouvert, peut-être ?
Concrètement, qu'est-ce que ça change que le port soit ouvert à travers Nginx ou directement par Seafile ?

Si tu fais référence à Sivens, ce sont des grenades offensives (et non défensives), qui ne sont pas spécialement dangereuses. 2 262 grenades de ce type ont été utilisées entre 2010 et novembre 2014 lors de manifestations, et je ne crois pas avoir entendu parler d'autant de morts.