flan a écrit 1865 commentaires

Je trouve plutôt étrange de hard-coder une politique monétaire (qui n'a aucune raison d'être fixe, au contraire elle devra varier en fonction du contexte) dans la monnaie (tout comme je trouverais étrange de la coder en dur dans une constitution).

La politique monétaire, comme la monnaie, est un outil au service de l'économie et va forcément varier. Le new deal des années 30 n'est pas viable dans tous les contextes, par exemple.

Et du coup injecter dans les pages des ressources venant de n’importe où ?

C’est pourtant ce qui a été expliqué.

Cela dit, ils ont peut-être voulu dire que le serveur (au sens code source) serait disponible.

Personnellement, je n'utilise que fpm pour créer des paquets Debian.

https://fpm.readthedocs.io/en/latest/index.html

quel conflit d'intérêt ?
L'État a besoin d'une messagerie interne qu'il maîtrise réellement et le met donc en place, en s'appuyant logiquement sur un composant qui ne lui coûte rien ou presque plutôt que de réinventer la roue.

Maintenant, ça ne coûte rien de le mettre à disposition de n'importe qui, donc autant le faire, mais il ne faut pas oublier que ce n'est absolument pas le but premier de la manœuvre.

bah bien sûr qu'il y a du vieux code qui traîne, c'est une évidence… mais maintenant, toutes les grandes bibliothèques sont en Python 3 (il suffit de regarder https://python3wos.appspot.com pour avoir une idée : sur les 200 plus téléchargées, 190 sont en Python 3 et sur les 10 restantes, 8 sont des outils internes de Mozilla, 1 est maintenant en Py3 et la dernière a été intégré à Py3), Python 3 est disponible par défaut sur les distribs comme Ubuntu contrairement à Python 2, etc.
Sauf cas de force majeure, il n'y a plus aucune raison de faire du Python 2 pour un nouveau projet.

Il n'y a plus vraiment de clivage en Python. Globalement, maintenant, c'est du 3 partout et c'est tout.

il y a également la possibilité de charger un profil en fonction de quelques variables (user, hostname, …). Ça permet donc faire un terminal par défaut à fond noir, puis quand on se connecte en SSH sur une machine, il devient vert, puis rouge quand on enchaine sur un sudo -i, ou bleu pour tout autre utilisateur. Ça permet d'éviter bien des erreurs =)

J'utilise Tilda pour ça (et iTerm2 sur macOS, que je trouve également fantastique comme ses autres utilisateurs, j'ai l'impression), mais il ne fonctionne pas sur mon Ubuntu 17.10 :(

Je n’ai pas dit qu’il n’était pas disponible mais qu’il n’était pas installé sur une Ubuntu de base.

Je ne connais pas toutes les distribs, mais Ubuntu ne propose que python3 par défaut (python2 n'est pas installé).

À peu près tous ceux que je connais ont réussi à se le faire payer par leur employeur, ou ont craqué à titre personnel. De mon côté, j'ai une license personnelle (mais je vais essayer d'en avoir une par le boulot).

Par exemple détecter si tu utilises un template inexistant, si dans le template tu utilises des filtres ou des variables inexistantes. Du coup, ça propose également de l'autocomplétion intelligente sur les noms de templates et des filtres ou variables. Ça permet de détecter que tu as oublier de charger une bibliothèque de templatetags.
Il propose de lancer les tests via Django quand tu fais un clic-droit sur un TestCase qui utilise la classe fournie par Django.

L'autocomplétion est également adaptée en Python, elle fonctionne avec les modèles (par exemple, si je tape User.objects.filter(, il va proposer username=, username_in, username_gt, … bref tous les filtres SQL disponibles) et les URL.

(et le README de pyimport m'a convaincu que PyCharm était beaucoup plus pratique pour ça :) )

Comme beaucoup, j'utilise PyCharm (Pro) pour faire du Python.

À vu de nez (je ne suis pas spécialiste Emacs), par rapport à PyCharm, il manque à ta configuration
- la détection automatique pour exécuter du code (clic-droit sur une docstring : il propose de lancer doctest, sur un fichier normal : il propose le fichier normal, sur un fichier de tests : il propose unittest, etc.)
- la gestion complète de Django et autres framework
- la gestion de la couverture de code
- l'inférence de type
- les imports automatiques (copier-coller d'un bout de code, et là tu fais Alt-Entrée -> Entrée pour chaque import manquant, sans même être sur la bonne ligne)
- la gestion du setup.py (par exemple tu ajoutes un package XXXX à ton setup.py, il propose de faire un pip install XXXX, ou au contraire si tu utilises YYYY, il te propose de l'ajouter à ton setup.py)

pour le libre, ça dépend des langages : il y a des versions libres et gratuites d'IntelliJ et PyCharm.

C'est a priori déjà possible, il suffit de faire tourner fail2ban sur un collecteur rsyslog.
Enfin, failt2ban ou tout autre système (graylog permet de le faire, par exemple)

on sait qu'il y a un déséquilibre et on veut en sortir.

pourquoi devrait-on sortir de ce déséquilibre, tant que chacun peut faire ce qu'il veut sans être gêné ?

Je suis conscient de répondre à côté de la plaque, mais avez-vous des raisons particulières de ne pas utiliser SQLAlchemy ?
Cette bibliothèque permet d'utiliser SQLite beaucoup plus facilement et d'éviter un certain nombre d'erreurs.

http://sametmax.com/les-critiques-des-orm-sont-a-cote-de-la-plaque/ (note : le slogan du blog est « du code, du cul » et ça peut être très explicite…)

Pas de typage dans les déclarations de méthode, même pas en commentaire
Ça rend la doc des fonctions, classes et modules juste misérable. Si au moins on pouvait avoir un équivalent de PHPDoc, et qu'il soit accepté par la communauté comme un standard, ça aiderait.

Je ne comprends pas trop… Pour la doc, il y a sphinx qui est très clairement le standard de facto, et tu peux indiquer le type comme tu veux. Tu peux également utiliser le TypeHinting, qui est utilisé par les IDE dignes de ce nom.

Les modules
Je sais que ça commence à s'améliorer doucement avec python3 et des brouettes, mais franchement, ça reste moisi. Et tout ça alors que c'est un besoin primaire de programmation de pouvoir facilement diviser son code en plusieurs fichiers. Ça trouve le moyen d'être plus louche que PHP composer et ses PSR.

Quel est le problème pour découper en modules ?

Je suis d'accord avec toi sur ce problème, et c'est dommage qu'ils n'aient pas profité de Python 3 pour changer également ça.
Enfin, ils ont déjà corrigé LE plus gros problème de Python 2 à mes yeux, qui était le mélange unicode/str.

Peut-être pour Python 4 ? :)

Python permet de développer vite, très vite, et en tout cas personnellement, je ne me vois pas développer aussi vite avec un autre langage de programmation (que ce soit grâce au langage lui-même, aux outils, à la bibliothèque standard ou aux bibliothèques existantes de façon générale).
Accessoirement, les morceaux qui ont réellement besoin de perf constituent rarement la majeure partie du code. Pour 95% du code (statistique complètement au jugé, évidemment), Python convient très largement.

Dans certains cas, c'est tout bêtement beaucoup plus rentable pour mon employeur de payer un ou deux serveurs supplémentaires que de me payer du temps supplémentaire à optimiser ou refaire dans un autre langage les parties requises.
Dans d'autres cas, c'est simplement un choix entre « un projet qui pourrait être plus rapide mais qui fonctionne » et « pas de projet du tout ». À nouveau, le choix est vite fait, même si on préférerait toujours avoir plus de perfs.

Je suis bien d'accord avec toi sur PyCharm. J'utilise beaucoup le TypeHinting, je n'hésite pas à rajouter s'il le faut des assert isinstance(x, y) ou un commentaire pour l'aider et je n'utilise que très exceptionnellement le typage dynamique (quand ça permet de vraiment simplifier le code). Au final, ça marche bien et j'ai vraiment très peu de bugs liés à des problèmes de type.

C'est de façon générale quelque chose de très demandé et étudié, on peut espérer du progrès à ce niveau (c'est également nécessaire pour augmenter les perfs).

Je voulais bien sûr dire que de toute façon on utilise des préfixes, avec plein de chiffres après la virgule qui sont perdus dans la nature. Bref, l'argument d'une pseudo-exactitude des Tio/Gio/… ne tient pas debout.

Quel était son inconvénient pour qu’on éprouve le besoin de changer ?

• garder le vrai sens des préfixes SI
• avoir des calculs plus simples et sans ambiguïté de façon générale
• avoir des conversions qui soient simplement… exactes (et oui : on a 1,023 kio = 1 047,55 o… ou 1 047 o = 1,022460[…] kio : conversion exacte impossible dans les deux cas)
• permettre des conversions et des comparaisons d'un coup d'œil (peux-tu comparer 0,49 Tio et 500 Gio ? )

Au final, on a quand même une habitude qui n'apporte pas grand-chose, voire rien du tout (les *io) face à un système (le SI) largement éprouvé, répandu et efficace.

Ça tombe bien, le parsec n'est pas une unité du SI, qui reste donc bien cohérent (et non consistant).

Du coup, la question, c'est pourquoi utiliser des puissances de 2 ?
Pour l'adressage ?

dans ce cas, on utilise de l'hexadécimal, et ce n'est pas pour indiquer réellement une taille (et donc on n'utilise pas les préfixes, vu qu'on veut l'adresse en entier)

Pour indiquer aux gens la capacité des machines qu'ils utilisent ?

je ne vois pas en quoi les puissances de 2 indiquent mieux la capacité des machines que les puissances de 10.

Pour comprendre ce que peux contenir un disque dur que l'on va acheter?

idem. Je peux immédiatement comparer un disque de 0,49 To et un disque de 500 Go. Peux-tu faire la même chose avec des disques de 0,49 Tio et de 500 Gio ?

En quoi la norme SI (même pas ISO) est-elle débile ?

Pourquoi utiliser un mélange de puissances de 10 et de puissances de 2 ? Quel est l'avantage de ce mélange, en fait ? Dans 99,9% (statistique au doigt mouillé particulièrement fiable, évidemment), on parle de toute façon en Mo, Go voire To, avec une valeur exacte qui ne s'exprime facilement ni en puissances de 2, ni en puissances de 10.